OSD на ATmega1281
Я пытаюсь её избежать
И как? Двадцатый раз… Про сервы забудем… Первым делом подключил ноут через DC/DC без развязки к прикуривателю. И к прикуривателю же подключил приемник. Соединил по видео ноут-приемник,- жуткая помеха на картинке на ноуте. Питание приемника проверил осциллом - все чисто. Ваши действия?😉
Ну пытаться опровергать магические свойства LDO по сравнению с простыми линейниками уже лениво… А с импульсниками сравнивать как бы некорректно…
Потому сейчас многие задачи, которые раньше решались только импульсниками, могут быть решены LDO.
Очень узкий круг задач. Когда разница между входом и выходом гарантировано больше 2В практически без разницы LDO или простой линейник.
Ладно, офф затянулся…
Поскажите, как лучше сделать миникарту? Самое очевидное натаскать jpeg-ов из какой-нибудь “планета-земля” и сделать ручками привязку к координатам. Но наверняка более приличное решение есть…
Правда, строго говоря, это тоже офф…
совсем даже не офф 😃
посмотреть на openpilot.org - там под qt4 все это сделано
и кросплатформа реальная ,и под лицензией правильной 😃 😃 😃
те можно надергать и сделать свое со своей функциональностью
Питание приемника проверил осциллом - все чисто.
Я так понимаю, приёмник был также подключён к прикуривателю? Тогда какой смысл был проверять его питание? Помеха очевидно идёт от БП либо с его выхода, через цепи ноутбука (землю например), либо, что вероятней, от самого БП по воздуху. Вы бы фотку хитросплетений проводов показали, стало бы яснее.
Если же приёмник был подключён после БП, то там в принципе не могло быть чистого питания 😉
Ну пытаться опровергать магические свойства LDO по сравнению с простыми линейниками уже лениво…
Выделять анахронизмы системы 7805 в отдельный класс “обычных линейников” Ваша иницатива. Сейчас все линейники ЛДО, даже КФ1158ЕН501А.
Я же пытался отговорить от применения импульсника, ибо в вашей задаче он не нужен. Ну и от 7805 за одно, т.к. к ней тут на форуме питают явную любоффь. Ну да дело ваше. Я таких проблем не имею, питая наземку как от прикуривателя, так и от USB ноута (версия без слежения). Кстати, есть там версия и с ИБП, сепиком, чтобы питать наземку от 2-4 банок липоля. Но тут уж без ИБП никак…
А с импульсниками сравнивать как бы некорректно…
Импульсники бывают разные. Грести все под один шаблон тоже некорректно.
Поскажите, как лучше сделать миникарту? Самое очевидное натаскать jpeg-ов из какой-нибудь “планета-земля”
Так все и делают, тот же Ози. Самый простой и верный вариант.
Я таких проблем не имею, питая наземку как от прикуривателя
А как запитываете ноут? Пока я его запитывал через инвертер->БП ноута тоже проблем не было…
БП Наземной станции теперь поприличнее выглядит 😃
Наконец заставил себя обновить схемку осд/ап. Сложно назвать ее окончательной, куча компромиссов… Добавлен канал звука (примитивный унч, даже без ару, плюс пассивный микшер). Добавлен компаратор для группового ппм с приемника (навороченные приемники оказалось могут вообще не иметь компаратора, аналоговый сигнал сразу у них подается на ножку проца). Вся аналоговая часть сейчас собрана на отдельных мелких платках. надоели сопли, решил перенести на одну плату хотя бы ее. Может кому будет интересно…osd.rar
А как запитываете ноут?
Через китайский БП для ноутбуков, универсальный, стоимостью 570р. В комплекте переходники на все модели. Ещё 50р отдал за тройник в прикуриватель. Через тройник питание уходит на наземку. Версия без слежения питается от одного линейника (можно питать прям от ЮСБ), версия со слежением имеет дополнительно два на каждую серву. Линейники были чуть тёплые в наше сумасшедшее лето, радиаторов нет, все корпуса SMD. Это я к тому, что ваша серва никогда 500 мА на постоянке не возьмёт (если её не стопарить, но в этом случае сработает защита ЛДО по току или температуре).
И вся любовь.
Вообще пришёл к выводу, что блок слежения надо делать самостоятельным. Со своим питанием, а наземку питать от ЮСБ. С наземки кабелёк на блок слежения. Ибо далеко не всегда данный блок нужен.
Последний вариант схемы могу выложить (надо только себя заставить нарисовать…), hex-ом последней версии поделюсь безвозмездно, те. даром…
Удалось себя заставить 😉?
(Если - “нет”, то, PLS, хотя бы в двух словах: в чём отличие от первоначальной схемы?)
Дык сообщение 222… Там правда тоже неточности по номиналам есть, но пока повторять никто не собирается- не принципиально…
ЗЫ Очень медленно и жутко лениво пишу софтину для наземной станции. С захватом видео (DirectDraw), мини-картой (свой движок), виртуальной приборной панелью, трендами параметров. Такими темпами, не уверен, что вообще закончу…
Дык сообщение 222… Там правда тоже неточности по номиналам есть, но пока повторять никто не собирается- не принципиально…
Признаю свою ошибку - проглядел!!! (Когда тема ушла в сторону БП - читать стал менее внимательно…😌)
А теперь, восстановив былые навыки кодинга и получив АрдуиноМега1280 - решил начать с повторения чужого опыта. Поэтому, (если не сильно затруднит), можно чуть-чуть подробнее о неточностях в номиналах…😋
P.S. забыл сказать САМОЕ главное: Большое Спасибо!!!
За длинные выходные, в перерывах между “отмечаниями” великого празника, осилил передачу телетексто-подобных тестовых строк с OSD на свою GrounStation. Передаю в двух строках по 24-байта. 1,5 байта теряется на синхронизацию+0.5байта номер фрейма+2байта на CRC итого в остатке 40 байт чистых данных на полукадр. Более чем достаточно выдать практически все что можно с самолета, по сути в реальном времени…
Тоже озадачился данной темой, если не секрет расскажите по подробней алгоритм синхронизации начала посылки, есть ли привязка к КСИ и ССИ или вполне возможно выловить синхробайт из видео сигнала, а также пару слов ,как реализована аналоговая часть декодара ?
есть ли привязка к КСИ и ССИ
Да. Первоначально планировал синхру ловить встроенным в мегу компаратором, а для данных- внешний LM311. Но почему то (не понял почему) данные надежнее (при больших изменения опорного напряжения) хватались через встроенный компаратор, хотя по дш быстродействие у него значительно меньше… Пришлось внешний пустить для синхро. Знал бы, поставил вместо него 1881…
Так что по импульсам видео-синхронизации, отсчитываю нужный номер строки от начала кадра, дальше захват синхро-байта и синхронный прием.
как реализована аналоговая часть декодара ?
Был уверен, что выкладывал схему… За точность номиналов не гарантирую, может что слегка менял…
В принципе могу и исходники GS выложить, но там понять кроме меня что-то довольно сложно…😃
ЗЫ Забыл для 311 подтягивающий резистор на выходе нарисовать…
Если есть привязка к СИ видео сигнала, зачем тогда нужен целый синхро байт? почему нельзя сразу начать прием данных после нужного ССИ за старт используя первый же перепад уровня по типу USARTA . А уж если использовать синхронизирующую последовательность байт, то ведь можно её отловить и без видео СИ, и как мне кажется так будет более надежно.
Проводились ли испытания на устойчивость передачи данных в условиях плохого приема изображения ?
Если исходники не на СИ то интересно былобы взглянуть ,особенно интересует начало приема синхро байта и момент где принимается решение, что закончился синхробайт и начинаем прем пакета. если не в напряг то это место с коментами, или просто на словах опишите процедуру.
За ламерские вопросу прошу сильно не пинать, так как в теме не оч. шарю,и пытаюсь вникнуть в суть.
Спасибо за внимание !
Если исходники не на СИ то интересно былобы взглянуть
А если на С, то тогда уже мне тоже интересно взглянуть!
Проводились ли испытания на устойчивость передачи данных в условиях плохого приема изображения ?
Полевых испытаний пока не проводил. Имитируя плохой сигнал интерференциями в комнате, вполне доволен результатом. Пока картинка хоть немного читаема, данные, хоть и с дропами, идут.
зачем тогда нужен целый синхро байт?
Ну это не синхро-байт в полном смысле слова. Нужен лишь его передний фронт для фазовой синхронизации. А дальше время входа в процедуру прерывания, сохранение регистров, инициализация… Вообщем на все про все теряю 1,5 байта (5 бит пропускаю, дабы сразу попадать бит в бит не занимаясь дополнительно их сдвигами). Может и возможно сделать многие вещи заранее и не “зарыться” в стеке при всех возможных ситуациях, ну уж как сделал…
А уж если использовать синхронизирующую последовательность байт, то ведь можно её отловить и без видео СИ
Представляется очень сложно… Ведь потребуется постоянная фазовая коррекция, а с ней будут пропуски бит… К тому же надо еще и сервами успевать шевлить и светодиодами моргать и на хост данные сливать…
Вообщем пока так:
прерывание от синхроимпульсов:
//-----------------------------------------------------
interrupt [EXT_INT0] void ext_int0_isr(void)
{ // ССИ+КСИ
u_char ind;
static u_char fpv=0;
if(!(PIND & 0x4)) TCNT2=0; // Начало СИ
else
{ // Окончание СИ
if(TCNT2>30) { gNumLine=0; return; } // КСИ
if(gNumLine<200) gNumLine++;
if(gNumLine>=START_LINE_TT)
{ // Пора поработать...
if(fpv) return; // повторное вхождение, ай-ай..
fpv=1;
ind=gNumLine-START_LINE_TT;
if(ind<COUNT_LINE_TT)
{ // Точно пора работать..
gVideoBuffPoint=gVideoBuff[ind]; // Указатель на буфер для приема
ACSR=0x1B; //AC_int=rising, int_flag=clear
MCUCR=0x80; //sleep=enable, int0=disable
#asm("sei")
#asm("sleep") //wait AC_int, всего готово, спим и ждем прерывания от синхро байта
}
if(ind==COUNT_LINE_TT)
{
#asm("sei")
rec_v_data(); // Разбираем, что напринимали.. Контроль CRC, распихиваем по структурам..
}
fpv=0;
}
}
}
Продолжение следует… (Если еще кому интересно…)
Продолжение следует… (Если еще кому интересно…)
КОНЕЧНО интересно!
В целом идея понятна, примерно так себе и представлял.
Ведь потребуется постоянная фазовая коррекция, а с ней будут пропуски бит…
а это еще зачем ? Фазу чего и относительно чего нужно постоянно корректировать? Пока проблему вижу только в том, как понять среди шума , что пошли данные, не потратив на синхронизацию большую часть строки, так как длина пакета с синхронизацией ограничена по времени ССИ.
К тому же надо еще и сервами успевать шевлить и светодиодами моргать и на хост данные сливать…
а уж это то и вовсе второстепенная задача, так как не получив данные нам просто незачем шевилить сервами и нечего отсылать на хост, и можно спокойно всё внимание и время проца пустить на поиск и отлов пакета с данными, а уж приняв его появляется заведомо известное время до следующего пакета на все работу , зарядить таймеры на отсчет ппм импульса сервам много времени на требуется, а все обсчеты и и отправку данных на хост можно делать и не за один кадр (не столь критичная задача), про моргание диодиками даже на заикаюсь.
Фазу чего и относительно чего нужно постоянно корректировать?
Момент чтения бита видеоданных из порта должен по возможности приходиться на середину бита. Именно для этого укладываю спать МК в ожидании прихода первого фронта данных. При этом время неопределенности момента чтения составит 1такт проца, что всего в 4 раза меньше длины бита данных. Естественно из-за несинхронности кварцев, фаза момента чтения будет сдвигаться. На длину строки хватает, оценивал в цифрах…
Не настаиваю, возможно как-то сделать по другому, но пока не представляю практическую структуру такой программы…
Собственно дальше все просто, приходит первый бит, генерируется прерывание, и в нем синхронно читаются данные в буфер:
//-----------------------------------------------------
#pragma savereg-
interrupt [ANA_COMP] void ana_comp_isr(void)
{
#asm
ST -Y,R16 ;2t
ST -Y,R17 ;2t
ST -Y,R18 ;2t
ST -Y,R26 ;2t
ST -Y,R27 ;2t
IN R16,SREG
ST -Y,R16
;
MOV R26,gVideoBuffPointL ;1t
MOV R27,gVideoBuffPointH ;1t
LDI R16,(BYTES_FROM_STRING-1) ;1t
;
LDI R17,5
_wait_n: ; skeep 5-bits
DEC R17
NOP
BRNE _wait_n
NOP
; SBI 0x12,3 ;PORTD.3=1
_in_ch:
SBIC 0x8,5 ;ACSR & 0x20
SBR R17,0x10
NOP
NOP
SBIC 0x8,5 ;ACSR & 0x20
SBR R17,0x20
NOP
NOP
SBIC 0x8,5 ;ACSR & 0x20
SBR R17,0x40
NOP
NOP
SBIC 0x8,5 ;ACSR & 0x20
SBR R17,0x80
MOV R18,R17
CLR R17
SBIC 0x8,5 ;ACSR & 0x20
SBR R17,0x1
ST X+,R18 ; 2t
SBIC 0x8,5 ;ACSR & 0x20
SBR R17,0x2
NOP
NOP
SBIC 0x8,5 ;ACSR & 0x20
SBR R17,0x4
SUBI R16,1 ;1t
NOP
SBIC 0x8,5 ;ACSR & 0x20
SBR R17,0x8
BRSH _in_ch ;2t
;
LDI R16,LOW(0) ;ACSR=0x0; //AC_int=disable
OUT 0x8,R16
LDI R16,LOW(1); MCUCR=0x01; //int0=enable, sleep=disable
OUT 0x35,R16
; CBI 0x12,3 ;PORTD.3=0
;
LD R16,Y+
OUT SREG,R16
LD R27,Y+
LD R26,Y+
LD R18,Y+
LD R17,Y+
LD R16,Y+
#endasm
}
#pragma savereg+
//-----------------------------------------------------
Ну а для особо пытливых - весь проект: GS.rar 😃
Возможно не совсем по теме, но все же интересно, с какой целью в прерывании используется такой извращенный метод сохранения регистров, вместо PUSH и POP обычно применяемых в таких случаях?
Исходник глянул , но будучи написанный на С, (что для меня равносильно китайской грамоте) данный трюк не прояснил.
Честно говоря не разбирался, почему CVAVR использует стек, адресуемый SP, только для хранения адресов возврата из подпрограмм. А для всего остального использует Data Stack, адресуемый Y регистром. Просто принял правила игры. Могу выложить asm, который генерит CVAVR для этого проекта…
Могу выложить asm, который генерит CVAVR для этого проекта…
Спасибо не не надо, разобраться в том что сгенерит компилятор без подробных комментариев, я все равно не смогу. Просто подумалось ,что это не стандартное решение кактойто задачи (стараюсь запоминать такие финты), но раз это просто особенности компилятора и привычки то не стоит заморачиватся.
Меня вот больше интересует, как у вас в телеметрии строится линия горизонта (если конкретней то наклон и вращение), это геометрическое построение или же зарание подготовленные изображения с разными углами?
Спасибо не не надо
Я забыл смайлик поставить… 😃 Хотя в OSD часто пользовался таким приемом, быстренько писал на си, компилил, смотрел что там CV наассемблировал и оптимизировал уже готовый асм-код. Быстрее получается, тем более с асмом меги никакого опыта нет.
это геометрическое построение или же зарание подготовленные изображения с разными углами
Конечно геометрия(считаются координаты) плюс графика(рисуются линии). Самое время-прожорливое,- отрисовка текста, пришлось все на асме оптимизировать…