Телеметрия (часть 1)
На старых компах была как раз FSK и она записывалась на ленту. И не через делитель, а через капацитор. И коррекция ошибок там нехилая, равно как и сейчас в CD, флешках и винтах. Просто делается это втихую и “на первый взгляд как будто не видна” 😃
FSK характерна тем, что волна не рвётся при смене частот. Это есть хорошо по целому ряду причин. А дискретный сигнал всей своей сутью разрывный. Что есть очень плохо.
По этому можемы работают на FSK а не “через делитель” 😉
КАПАЦИТОР - это конечно круто.😒
Только вот на Радио-86 выход организован на делителе (пара сопротивлений -великоват уровень для линейного входа) и паре конденсаторов для обрезания частот сверху и низу.
И никаких спецмикросхем для FSK. Программно решается.
А с коррекцией ошибок ноут справится не хуже Радио-86.И не нужно опять же никаких микросхем - с выхода приемника сразу на вход линейный ноута.
Ну да ладно. Ясно что самая короткая дорога та которую знаешь.
Хотя явно не лучшая.
Можно и в термоусадку, не вопрос …
А никто не в курсе, какая полоса у аудиоканала видеокамеры?
Судя по тому что железо и схемотехника применяется та же что и в спутниковых ресиверах и видеосендерах - то не менее 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
Это не означает, что спецмикросхемы не нужны. Это означает, что люди смоги сваять их аналоги на МК, и не более того.
Это не означает, что спецмикросхемы не нужны. Это означает, что люди смоги сваять их аналоги на МК, и не более того.
Противоречите сами себе.
Так нужны или нет?Можно обойтись без них?😁
Вроде я просто выражаю мысли свои.
Нигде я не писал что делитель заменит спецмодемную микросхему.
А писал о том, что можно обойтись минимумом деталей (согласовать уровни,
развязать пост. составляющую и чуть отфильтровать) а все остальное сделать програмно - на передающей стороне уже имеющимся микроконтроллером, на приемной -процессором ноута.