Телеметрия (часть 1)
Можно и в термоусадку, не вопрос …
А никто не в курсе, какая полоса у аудиоканала видеокамеры?
Судя по тому что железо и схемотехника применяется та же что и в спутниковых ресиверах и видеосендерах - то не менее 15 кГц.
рад что автопилот продвигается, скоро smalltim его доделает - и откроет исходники телеметрии - а там хочешь и аудио канал дописывай 😃) Еще вопросик про цифры - если привязатся к строкам для аудиомодуляции, 312 строк на 50 полукадров - как раз частота 15 кгц получается, как я понимаю? Не спроста это -))
КАПАЦИТОР - это конечно круто.😒
Только вот на Радио-86 выход организован на делителе (пара сопротивлений -великоват уровень для линейного входа) и паре конденсаторов для обрезания частот сверху и низу.
И никаких спецмикросхем для FSK. Программно решается.
А с коррекцией ошибок ноут справится не хуже Радио-86.И не нужно опять же никаких микросхем - с выхода приемника сразу на вход линейный ноута.
Ну да ладно. Ясно что самая короткая дорога та которую знаешь.
Хотя явно не лучшая.
Программно FSK не решится, а капацитор был в любом случае, в схеме линейного входа магнитофона.
Насчёт двух конденсаторов для обрезания частот - не уверен. Можно увидеть схему, которую Вы имеете ввиду? Радио-86 был проектом свободным и каждый добавлял туда то, во что горазд.
Не надо приводить в качестве образца радиолюбительский проект 20-и летней давности, созданный в условиях советского дефицита. В нормальных компах был полноценный FSK.
Например, в радио-86 небыло микроконтроллеров с флеш-памятью. Теперь весь проект будем переводить на к155ла3? 😃 Зачем тогда столько лет производители выпускают микросхемы FSK модуляции, если они никому не нужны?
Наконец, у радийщиков есть поговорка: “потеряное в антенне не восстановит ни один усилитель”. Будь у Вас хоть пятиядерный пентиум, если на входе белый шум, ничерта Вы из него не выделите.
И дело не в том, какой путь знаешь, а в том, какой путь правильный. Проведите эксперимент и убедитесь 😉 Я уже провёл: forum.skunksworks.net/Forum5/HTML/000243.html
С автопилотом обнаружился небольшой косячок. На разъеме SPI для связи телеметрии и автопилота не выведен сигнал SS.
Если еще учесть, что я не имею права со стороны автопилотной платы вмешиваться в процессы на плате телеметрии (например, никаких прерываний от SPI) пока идет отрисовка ТВ строки, то получается, что данные придется передавать только тогда, когда плата телеметрии будет готова это делать - в середине кадра и на межстрочных интервалах.
Мысль такая: SPI на телеметрии всегда slave, и на запросы от мастера на плате автопилота всегда отзывается нулями или никак не отзывается. А вот когда телеметрия реально готова обмениваться данными, включает SPI и отзывается спецпакетом типа 0х00,0хFF,0x00,0xFF, а дальше понеслась. Мастер видя такой пакет начинает передавать актуальные данные телеметрии, а телеметрия отзывается пачкой данных с сенсоров. Получив полный пакет данных и передав что нужно, мастер отсылает опять же что нибудь типа 0х00,0хFF,0x00,0xFF. Видя такое на SPI, телеметрия отправляет SPI спать до следующего подходящего момента.
Мастер, в свою очередь, с неким интервалом постоянно шлет в телеметрию что-нибудь в надежде увидеть в ответе спецпакет означающий готовность к обмену данными.
Что скажете, жизнеспособно?
С SS на самой плате автопилота проблем нет: атмега там всегда мастер, память - slave, сигнал SS корректно разведен.
Можно увидеть схему, которую Вы имеете ввиду?
С автопилотом обнаружился небольшой косячок. На разъеме SPI для связи телеметрии и автопилота не выведен сигнал SS.
Если еще учесть, что я не имею права со стороны автопилотной платы вмешиваться в процессы на плате телеметрии (например, никаких прерываний от SPI) пока идет отрисовка ТВ строки, то получается, что данные придется передавать только тогда, когда плата телеметрии будет готова это делать - в середине кадра и на межстрочных интервалах.
///----
Мысль такая: SPI на телеметрии всегда slave, и на запросы от мастера на плате автопилота всегда отзывается нулями или никак не отзывается. А вот когда
Мастер, в свою очередь, с неким интервалом постоянно шлет в телеметрию что-нибудь в надежде увидеть в ответе спецпакет означающий готовность к обмену данными.
Что скажете, жизнеспособно?
Вполне, уже 5 лет как по подобному алгоритму работаю 😉
только внешних устройств от автопилота побольше 😝
Для экономии времени со стороны автопилота лучше не отзываться никак- время простоя- всего один с хвостиком символ. Хотя это от распределения времени зависит, может автопилоту выгодней будет пару раз в секунду 20мс подождать 😃
Мысль такая: SPI на телеметрии всегда slave, и на запросы от мастера на плате автопилота всегда отзывается нулями или никак не отзывается. А вот когда телеметрия реально готова обмениваться данными, включает SPI и отзывается спецпакетом типа 0х00,0хFF,0x00,0xFF, а дальше понеслась. Мастер видя такой пакет начинает передавать актуальные данные телеметрии, а телеметрия отзывается пачкой данных с сенсоров. Получив полный пакет данных и передав что нужно, мастер отсылает опять же что нибудь типа 0х00,0хFF,0x00,0xFF. Видя такое на SPI, телеметрия отправляет SPI спать до следующего подходящего момента.
.
Это слишком сложно. Вполне достаточно выключать SPI на плате телеметрии, оставляя подтяжки. Тогда мастер будет читать FF. Как только телемертия готова, включить SPI и мастер считает 00. А далее передавать пакеты фиксированой длины, с нумировкой. У меня подобным образом работает. Пакеты 10 байт, длина рассчитана так, чтобы везьде успевать пролезать.
Можно, конечно, с подтверждением, но есть риск, что в кореектном пакете попадётся заявленая комбинация и будет сбой.
А можно принтскрин кусочка? У меня на этой машине дежавю нет, да и инет - нестабильный GPRS… 😦
Решил всунуть в свою телеметрию автопилот, нарисовалась следующая схемка. Отличительная особенность это питание мультиплексора от приемника, если что ни будь произойдет с телеметрией, зависнет, отрубится, замерзнет управление не потеряется. Поругайте если что не так. Форум фотку порезал, поэтому добавил в архиве дубль.
Доброго времени суток.
Имею EasyStar с передатчиком и OSD от RangeVideo. Все интересно, но хочется еще иметь на Ozi отметку положения. Возникла идея, и по форуму понимаю - правильная, передавать nmea по аудиоканалу. Т.е. нужен еще один GPS-приемник (OSD-шный пусть работает сам по себе), чип кодирования в аудио и вместо микрофона передатчика на борту. На земле с аудиовыхода приемника декодируем и на вход ноутбука.
Вопрос. Имеет ли смысл такая реализация и если да, то как?
Заранее спасибо за ответы.
Доброго времени суток.
Вопрос. Имеет ли смысл такая реализация и если да, то как?
Заранее спасибо за ответы.
Вот уже всё придумано до нас
dzl.dk/projects/electronics/modem/modem.html
Передавать не пробовал. Но ради интереса прошил в tiny2313 прошивку tx. На соответсвующей ножке была генерация прямоугольных импульсов. При подаче данных что-то в этих импульсах менялось.
Вот уже всё придумано до нас
делал, работает
естественно при условии согласованности с аудиотрактом, дабы небыло искажений
А зачем второй ГПС? можно же паралельно отбирать пачки данных с одного модуля.
Для разработки приложения отображения параметров телеметрии на ПК (Windows XP) начали обсуждать протокол передачи.
Matlab поставьте. С подобными вещами управляется на ура, за пять минут любой “экран” набросать можно с графиками, готовыми приборами(авиа притом).
Это слишком сложно. Вполне достаточно выключать SPI на плате телеметрии, оставляя подтяжки. Тогда мастер будет читать FF. Как только телемертия готова, включить SPI и мастер считает 00. А далее передавать пакеты фиксированой длины, с нумировкой. У меня подобным образом работает. Пакеты 10 байт, длина рассчитана так, чтобы везьде успевать пролезать.
Можно, конечно, с подтверждением, но есть риск, что в кореектном пакете попадётся заявленая комбинация и будет сбой.
А почему OSD slave должен быть обязательно, если на ней датчики висят???
К smalltim вопрос: сколько прерываний помимо на Vsync и Hsync от LM-ки??? Скорее два байта в начале пакета для синхра: 0xAA, 0x55(стандартный feed). Один хрен OSD только в начале и в конце кадра имеет свободное время для доп. прерываний(в вашем варианте возможно и по центру), а в автопилоте с этим попроще будет. Т.е. с букафками беда начнется однозначно, если она слэйвом начнет пакет ловить не в нужном месте. А если графика на весь экран? Тогда еще вариант: завести синхроимпульсы с LM-ки на автопилот и по ним синхронизировать: в начале строки обмен по байту, а в первых двух строчках синхробайты- тогда в OSD только на SPI прерывание останется+пакет длиной в количество строк можно сделать(в две стороны соотв.)+никаких проблем с синхроном протокола
Вот уже всё придумано до нас
Вот спасибо!
Теперь видно, что спецмикросхем модемных и не нужно.
Вот уже всё придумано до нас dzl.dk/projects/electronics/modem/modem.html
Спасибо большое. Точно в цель.
Надо будет вспомнить старое - спаять и прошить…
Может быть еще кто подскажет, как дальше сигнал GPS в ноутбук вогнать, чтобы Ozi работал? Через COM?
Matlab поставьте. С подобными вещами управляется на ура, за пять минут любой “экран” набросать можно с графиками, готовыми приборами(авиа притом).
Благодарю, попробую разобраться.
Вот спасибо!
Теперь видно, что спецмикросхем модемных и не нужно.
А тинька в этой схеме разьве не спецмикросхема модемная?
Там же написано - человек применяет BPSK ( ru.wikipedia.org/wiki/Фазовая_манипуляция ) а не тупо “через делитель на вход усилителя”.
Аналогичный проект был и для USB: cesko.host.sk/…/IgorPlug-USB (AVR) RS232_eng.htm
Это не означает, что спецмикросхемы не нужны. Это означает, что люди смоги сваять их аналоги на МК, и не более того.
Это не означает, что спецмикросхемы не нужны. Это означает, что люди смоги сваять их аналоги на МК, и не более того.
Противоречите сами себе.
Так нужны или нет?Можно обойтись без них?😁
Вроде я просто выражаю мысли свои.
Нигде я не писал что делитель заменит спецмодемную микросхему.
А писал о том, что можно обойтись минимумом деталей (согласовать уровни,
развязать пост. составляющую и чуть отфильтровать) а все остальное сделать програмно - на передающей стороне уже имеющимся микроконтроллером, на приемной -процессором ноута.
Я себе не противоречу. FX-614 работает на FSK, её вы никак не сгенерируете МК. Разьве только Cypress-ом и т.п., но НЕ АВР. При этом FSK - самая вкусная модуляция из всех.
Вы же писали, что достаточно всунуть меандр в аудиовход, причём даже без капацитора, и всё будет замечательно (кстати, открыт вопрос, как Вы собирались без капацитора развязывать пост. составляющую). Могу прямую ссылку дать.
BPSK можно генерить атмелом, но привязка ко времени весьма жёсткая. Если вы думаете, что обеспечить её одновременно с выполнением других задачь автопилота - плёвая работа, то флаг, как гриться, и барабан… Смалтим вон 50 Гц на ассемблере обрабатывает, и неспроста.
А если городить внешнуюю микру, то почему не применить готовое и отлаженое?
Насчёт ноута вопрос - а как вы собрались реалтайм делать на виндовсе?..
Упростим задачу - у вас ноут с ДОСом и с полноценными СОМ портами. Но даже в таких условиях мне в своё время пришлось писать спец процедуру извлечения системного времени, чтобы получть разрешение лучше 1 мС:
procedure getcount(var xtc:tc); assembler;
asm
push ds
mov si,$46c
xor bx,bx
mov ds,bx
mov al,$06
cld
cli
out $43,al
in al,$40
mov dl,al
in al,$40
mov dh,al
lodsw
mov bx,ax
std
lodsw
sti
not dx
mov cx,ax
lodsw
cmp ax,bx
jz @@1
or dx,dx
js @@1
inc bx
jnz @@1
inc cx
@@1:
pop ds
les di,xtc
cld
mov ax,dx
stosw
mov ax,bx
stosw
mov ax,cx
stosw
mov word ptr [es:di],0
end;
Если у вас получится измерять 5 кГц даже в досе или Qюниксе, с меня ящик. За такой же подвиг в XP - монумент и вечное поклонение 😃
Конечно, можно загнать поток в аудиовход и парсить как звуковой сигнал. Но это, как гриться, каждый извращается как может 😃 Я не понимаю тяги к созданию себе проблем путём снижения универсальности изделия… Одних кабелей сколько потребуется, для соединения всего этого барахла…
Мне коробочка с антенкой и USB шнурком как-то приятней.
FSK сгенерирую на микрконтроллере, правда скорость приемлимую не обещаю 😃) Отличие спецмикросхем от универсальных контроллеров только лишь в уровне быстродействия …
И фаза рваться не будет?
А в чем заморочки, если частота низкая? Считай синусы и складывай 😉
Дело не в частоте, а в загрузке МК. Увлечётся МК интераптами и передача сорвётся. Значит, надо писать софт с первым приоритетом для передачи, что чревато потерей самолёта 😃
И всё это ради того, чтобы не использовать специально заточенную под передачу микрушку 😃