Search in topic

Телеметрия (часть 1)

Далее, если прыгает изображение немного вверх, - вероятно, из-за сильного размаха видеосигнала некоторые выбросы обрабатываются как строчные СИ (опять же, это как у вас построен софт, можно время строчки учитывать) , и на считываются “лишние” строки. Как вариант, для борьбы с этим Можно попробовать поднять емкость входного шунтирующего конденсатора на 200-300 пф.

согласен полностью…😛
я конечно не летал при - 10 но у нас таких температур сейчас нет!!!😮
а при - 6 или около того все нормально пашет !!!😈
одна проблема GPS не коректно пащет по высоте…😮

Температуру можно решить компоновкой, завернуть в тряпочку и по ближе к регулятору оборотов, но то что LM1881 отрубается это факт

>одна проблема GPS не коректно пащет по высоте…😮

Это как? На морозе метры становятся меньше? 😃

Сделались платки автопилота, пирометров, тока.
Сразу прикинул, как будет выглядеть бутерброд из автопилота и телеметрии.

>одна проблема GPS не коректно пащет по высоте…😮

Это как? На морозе метры становятся меньше? 😃

в том то и проблема, что наоборот… :oметры на морозе почемуто становятся длиннее…😌

А что за GPS, чье, откуда?

Ой какие красивости, я тоже хочу такую платку 😦

Ну что сказать, Тимофей? Молодец! Да и остальные “бойцы невидимого фронта”
приложившие руку к этому проекту. Думаю Тимофей их сам всех перечислит лучше меня. Реальное устройство доведенное от идеи до воплощения в железе, по нынешним временам, это большая редкость.
Тем более приятно, что продукт получается действительно “народным”, массовым, достаточно простым и легко повторяемым. А главное составляет достойную конкуренцию забугорным изделиям.
Так держать!
Удачи, успехов, и новых достижений в Новом году!

Нада скидываться на WMR и заказывать двадцатку. Я с удовольствием руку приложу к программке

Для разработки приложения отображения параметров телеметрии на ПК (Windows XP) начали обсуждать протокол передачи.

Цель - использование единого ПО отображения для различных вариантов телеметрии.

ПК подключается к приемному устройству телеметрии через RS232 или через USB (RS232/USB конвертор).

Для различных приложений (вертолетных, планерных, самолетных и т.д), где передаются различные параметры, предлагается использовать или идентификатор протокола или идентификаторы параметров.

Предварительное обсуждение пока началось на Форуме у LeshaK здесь forum.leshak.ru/viewforum.php?f=4 , для входа в форум надо зарегистрироваться.

Приветствуется участие с конструктивными предложениями и особенно программистов, имеющих опыт написания подобных приложений для PC.

Привет Всем.
С Новим Годом.
Вопрос по ОСД плате:
Обясните зачем со стороны земли проведион Землианой проводник от акумулиатора?
Он всиоравно соединиаетсиа с землиой на “Крене”

>Обясните зачем со стороны земли проведион Землианой проводник от акумулиатора?

Чтобы земля для платы бралась с той точки, где стоят конденсаторы-помеходавы,
чтобы была меньше вероятность образования токовых петель.

smalltim, существуют ли сейчас варианты получения КИТа для сборки телеметрии?

>Предварительное обсуждение пока началось на Форуме у LeshaK здесь

Пока там обсуждения-то и нет особого.
Пару мыслей пока выложу тут.

1. На USB гораздо удобнее оперировать с паектами фиксированного размера.
2. Глянул скриншоты с графиками. Убожество. Я 2 года назад на flash за месяц написал просмотровщик данных (графиков) с , походу, невиданным для иглтриии функционалом. В мой вариант телеметрии перейдет 1 в 1, тока 3D добавится.
3. ИМХО, лучше делать систему максимально открытой: сделать ядро (логика там, работа с файлами и т.д.) и выставить наружу кончики API - позволить людям самостоятельно писать функции парсинга данных, отрисовки этих данных на экране, и т.д.

smalltim, существуют ли сейчас варианты получения КИТа для сборки телеметрии?

Отписал в личку.

>Я 2 года назад на flash за месяц написал просмотровщик данных
Вот картинка. Не показательная, но первая что нашел. Данные (до 32 графиков) берутся с жесткого диска или urlRequestами с любого http адреса или из баз данных. Структура меню, внешний вид и функционал настраиваются в XML файлах, само ядро на flash. Заточено всё под работу на строне сервера и отображение в браузере пользователя, но может работать и находясь локально на диске пользователя.

то smalltim. мне пожалуйста тоже ответьте по кит-у. я писал Вам в личку.

Отодвинув выпифку и салаты в сторону, потихоньку обрастаем мясом:

>Предварительное обсуждение пока началось на Форуме у LeshaK здесь

Пока там обсуждения-то и нет особого.
Пару мыслей пока выложу тут.

1. На USB гораздо удобнее оперировать с паектами фиксированного размера.
2. Глянул скриншоты с графиками. Убожество. Я 2 года назад на flash за месяц написал просмотровщик данных (графиков) с , походу, невиданным для иглтриии функционалом. В мой вариант телеметрии перейдет 1 в 1, тока 3D добавится.
3. ИМХО, лучше делать систему максимально открытой: сделать ядро (логика там, работа с файлами и т.д.) и выставить наружу кончики API - позволить людям самостоятельно писать функции парсинга данных, отрисовки этих данных на экране, и т.д.

Выскажу свою позицию по вопросу телеметрии, сугубо IMHO:

• вариант передачи телеметрии через видео изображение - удачное бюджетное решение для простой задачи полета в пределах 1,5 км.

  • Плюсы:

    • простота
    • дешевизна.

  • Минусы:

    • ограниченный радиус действия
    • невозможность записи в log параметров
    • невозможность анализа параметров полета
    • невозможность использования внешних приложений, использующих полетные параметры

• вариант передачи телеметрии в звуковом канале видео передатчика.

  • Плюсы по отношению к первому варианту:

    • увеличенный радиус действия при той же подводимой мощности видео передатчика
    • возможность записи в log параметров
    • возможность анализа параметров полета
    • возможность использования внешних приложений, использующих полетные параметры (например, наземная станция автоматически управляет антенной траверсой по углу места и азимуту, сопровождая модель в дальней зоне).

  • Минусы по отношению к первому варианту:

    • более сложное решение, требующее установки и на борту и на земле дополнительных блоков, обеспечивающих безошибочную передачу данных в радиоканале.

• вариант передачи телеметрии отдельным радиоканалом.

  • Плюсы по отношению ко второму варианту:

    • существенное увеличение радиуса действия получения телеметрических данных за счет использования узкополосных сигналов, безошибочной передачи и использования ретрансляторов
    • гарантированное получение телеметрических данных при существенно меньшей потребляемой мощности передатчика (соответственно меньше габариты и вес)
    • получение телеметрии не зависимо от видео картинки
    • наложение телеметрии на видео картинку в наземном блоке

  • Минусы по отношению ко второму варианту:

    • более сложный
    • более дорогой
    • требуется дополнительный передатчик телеметрии

Итак, если мы хотим иметь

• возможность записи в log параметров
• возможность анализа параметров полета
• возможность использования внешних приложений, использующих полетные параметры

следует использовать второй или третий варианты.

В этом случае встает вопрос об открытом протоколе передачи телеметрических данных с борта на наземную станцию - возможности декодирования на наземной станции данных, полученных с различных систем телеметрии.

Если протокол будет определен - а это первично, то создавать графические оболочки можно будет под различные требования.

Поэтому начать нужно именно с согласования протокола.

На мой взгляд, то что предлагает в виде интерфейса и послеполетных графиков EagleeTree вполне разумно и достаточно, хотя бы на первом этапе.

Не уверен, что обязательно и очень важно создавать клиент-серверные приложения с онлайн доступом, так как основная задача это локальный анализ параметров полета с возможностью воспроизведения из log файла и построения интересующих графиков.
А картинки в сеть/форум выкладывать уже не сложно при желании 😁.

Как уже говорилось, аудиосигнал пропадает намного раньше картинки, т.е. 2 вариант отметаем.
По 3 варианту:
во-первых, получается 2 передатчика на борту - некоторые и с одним передатчиком справится не могут - лезут помехи и уменьшается радиус действия р/у. Во-вторых, зачем мне нужны данные телеметрии на земле и большой радиус действия отдельного передатчика телеметрии, если картинка раньше пропадет? В этом случае намного проще писать лог на борту, а по прибытии на землю подробно рассмотреть его, хоть с помощью “внешних приложений, использующих полетные параметры”, проанализировать полет.
От того, что данные будут передаваться на землю - толку мало, если модель улетит - нечего и анализировать будет.
Путь, которым идет smalltim, самый правильный. Телеметрия+автопилот(на случай пропадания сигнала управления).
Если плюсом разработать платку логгера с записью полетных параметров в EEPROM, то это будет самый оптимальный вариант на мой взгляд.