Электронное оборудование ракет - БРЭО,часть XIV

http://www.kickstarter.com/.../hackrf-an-open-source-sdr-platform
Transmit or receive any radio signal from 30 MHz to 6000 MHz on USB power with HackRF.

И т.д.

RLAN> Если это проблема именно с манипуляциями файлами, может какой то RAM диск с периодическим сбросом на HDD спасет отца русской демократии?
Для начала попробуй в RAM, если поможет, то ставь SSD диск, должен будет успевать.

GOGI> Colors
GOGI> RocKI
GOGI> Skyangel
GOGI> ST
GOGI> Seemann
GOGI> письма получил.
GOGI> Еще наверное неделя есть...

Ссори за назойливость. Может,что то пропустил, или не получилось переслать? Готов приобрести за денюжку пару комплектов ( если ещё есть). Начал новый проэкт и нужно определиться с конфигурацией БРЭО...

Seemann> Ссори за назойливость.
Это что называется "Ой, бл.." Я ж забыл!!!
Расстреляйте меня, если на неделе не отправлю.

RLAN> Это действо выполняется другой командой SDK этой камеры. Временные параметры процесса частично известны. 5 мс - выдержка, 33мс - передача кадра через USB2.0.
а по сети не пробовали захватывать видео, вместо USB? И применить не входящий в комплект софт, а что-нибудь стандартное, типа FFMPEG

RLAN>> Это действо выполняется другой командой SDK этой камеры. Временные параметры процесса частично известны. 5 мс - выдержка, 33мс - передача кадра через USB2.0.
GOGI> а по сети не пробовали захватывать видео, вместо USB? И применить не входящий в комплект софт, а что-нибудь стандартное, типа FFMPEG
Спасибо.
Камера специфическая, обычными средствами не видна.

Делает то, что нужно, но вот с 25 кадрами при записи отдельными файлами не справляется (скорее не она а комп).
При замене HDD на RAM диск ничего не поменялось.
Даже не пойму, в чем задержка.
Предложили попробовать FAT32 вместо NTFS, вроде там не обновляются данные каталога при записи очередного файла. Промониторить процесс, посмотреть что и где?, чем лучше?

RLAN> Камера специфическая, обычными средствами не видна.
А, я думал это те Панасоники, что ты раньше писал. Я вот смотрю описание на них

пишут, что они могут быть directshow устройствами захвата. А после этого можно использовать все многообразие средств сохранения картинки с них.
Кроме того, там есть API для прямого доступа к камере.
Ну и, вдруг не видел, http://www.ids-imaging.com/frontend/...
RLAN> Предложили попробовать FAT32 вместо NTFS, вроде там не обновляются данные каталога при записи очередного файла. Промониторить процесс, посмотреть что и где?, чем лучше?
Если при записи на RAM диск не справляется, то это вряд ли уже поможет, затык скорее всего не в записи на диск. Даже если она по десять раз MFT будет переписывать на каждый файл.

GOGI> А, я думал это те Панасоники, что ты раньше писал.
Попрощался, для приличной задачи не нашел ни одной подходящей IP камеры.
GOGI> Ну и, вдруг не видел, http://www.ids-imaging.com/frontend/...
Этого не видел, почитал, спасибо.
Думаю, проблема не в этом, ведь поток пишет без задержек, как описано.
Созвонился с представительством в Королеве, где брал. Обсудили, обещал выслать варианты возможного решения. Они там пишут приложения для них.
Есть идеи, будем пробовать.

А пробовал DirectShow поддержку включить?
И вопрос, зачем сохранять отдельными кадрами?

GOGI> А пробовал DirectShow поддержку включить?
GOGI> И вопрос, зачем сохранять отдельными кадрами?
Так она включена. И приложения на нем работают. Но они сами достаточно убогие и нет нужных настроек. Это надо дописывать или все заново написать. Сам не могу, сына привлекаю. Но времени мало и хочется решить малой кровью. При этом нет гарантии, что это работает быстрее.
А вот зачем отдельными кадрами - вопрос интересный.
Я не придумал ничего другого, что бы связывать строку данных и картинку.
Ведь это полуфабрикат, его в дальнейшем надо обрабатывать для получения более точных значений угловых координат. Придумывать свой формат записи, потом под это писать софт для обработки - не увидел в этом логики. Рисовать данные в кадре оверлеем, не факт, что будет быстрее, потом распознавать - тоже через Ж...

RLAN>Но они сами достаточно убогие и нет нужных настроек.
А какие такие специфические настройки нужны. Тот же FFMPEG вообще кажется все на свете умеет
Тут единственный затык может быть в самом механизме передачи кадра от камеры, т.к. он по USB передается в каком-то своем формате, библиотекой преобразуется в понятный Directshow формат, а из него в программу захвата с последующим преобразованием. Но вообще современные компьютеры это достаточно легко должны делать.
RLAN> Я не придумал ничего другого, что бы связывать строку данных и картинку.
Я бы все-таки подумал над своим обработчиком. У вас все равно какая-то программа принимает данные с ком-порта, почему бы ей и не захватывать видео. У этих камер прекрасно описанный API под все распространненые языки, вроде сложного ничего я там не увидел. ИМХО под .NET можно за вечер заставить работать.

RLAN>> Я не придумал ничего другого, что бы связывать строку данных и картинку.
GOGI> Я бы все-таки подумал над своим обработчиком. У вас все равно какая-то программа принимает данные с ком-порта, почему бы ей и не захватывать видео. У этих камер прекрасно описанный API под все распространненые языки, вроде сложного ничего я там не увидел. ИМХО под .NET можно за вечер заставить работать.

Ты не ответил
В каком виде связать стробированные кадры и тем же стробированные строки данных?
Кадр и строка описывают определенный момент времени.
Имея поименованные кадры элементарно их потом обрабатывать и очень просто получить по желанию любой формат видео стандартными средствами.
Предложи другой вариант, я ничего лучшего придумать не смог.
А программа простая, взят пример из библиотеки и дописано пару небольших блоков.

RLAN> Ты не ответил
RLAN> В каком виде связать стробированные кадры и тем же стробированные строки данных?
Делаешь программой просто текстовый файл, где в начале строки идет номер кадра, а потом данные. Поскольку захватываешь своей программой, то легко получаешь номер текущего кадра, ну а дальше дело техники. Потом уже с одним видеофайлом и одним текстовым файлом будет много проще работать.

RLAN> Замечу дополнительно, что стандартная картинка
Ну так библиотека получает вполне стандартный AVI с MJPEG кодеком. Разобрать её потом на картинки это одна команда FFMPEG, если надо будет.

RLAN>> Ты не ответил
RLAN>> В каком виде связать стробированные кадры и тем же стробированные строки данных?
GOGI> Делаешь программой просто текстовый файл, где в начале строки идет номер кадра, а потом данные. Поскольку захватываешь своей программой, то легко получаешь номер текущего кадра, ну а дальше дело техники. Потом уже с одним видеофайлом и одним текстовым файлом будет много проще работать.

Не слишком понял.
В структуре потока MJPEG есть номер каждого кадра?
Как я вычислю пропуск кадра? (а они бывают)

RLAN> В структуре потока MJPEG есть номер каждого кадра?
Нет, но поскольку ты сам создаешь его, ты знаешь, к какому кадру привязано каждое сообщение ком-порта.
RLAN> Как я вычислю пропуск кадра? (а они бывают)
Смотри, насколько я прочитал API этих камер. Как нужно работать.
Отдельным потоком создается подключение к камере и ты начинаешь опрашивать камеру, по запросу камера кладет текущую картинку в заданную область памяти. На этом этапе, как я понял, пропусков кадровы быть не должно. Но вроде есть функция uEye.TimingVsyncCount.Get(out long s64Vsync, out long s64Fsync) которая дает номер текущего кадра и номер кадров вообще с момента запуска. По идее она должна позволять увидеть пропуски кадров, но повторюсь, на этом этапе их быть просто не должно.
Одновременно другой поток получает данные с ком-порта. Как только появился новый кадр, ты берешь его номер и к нему прикрепляешь сообщение. Хранишь пока в памяти.
А кадр с памяти ты можешь или сохранить на диск или передать его другой функции API камеры, которая пишет AVI по этим кадрам. Вот тут возможны пропуски кадров, если компрессор не будет справляться, но это тебе сразу выдаст ошибку при добавлении кадра и вот тут ты берешь сохраненный номер кадра и сообщение ком-порта и сохраняешь в файл, а если был пропуск кадра, то вместо номера кадра указываешь какую-нибудь метку что этот кадр в AVI пропущен.
Весь процесс записи видео описан очень хорошо, вот его краткий конспект

RLAN> Не могу я быть уверенным, что все идет без сбоев и пропусков.
Я вот не могу себе представить, где от камеры до ОЗУ компьютера может возникнуть затык, который приведет к пропуску кадра, это аппаратные вещи, они делаются в реальном времени. Ну не могут данные из буфера USB просто пропасть. Но если есть сомнения, ты можешь получать для каждого кадра TimeStamp и сохранять данные из ком-порта привязанные к нему.
Затыки идут в части или в части забрать кадр из памяти или сохранения видео или картинок. Все эти затыки во-первых, отлавливаются программно, во-вторых, их достаточно легко можно избежать.

RLAN>> Не могу я быть уверенным, что все идет без сбоев и пропусков.
GOGI> Я вот не могу себе представить, где от камеры до ОЗУ компьютера может возникнуть затык, который приведет к пропуску кадра, это аппаратные вещи, они делаются в реальном времени. Ну не могут данные из буфера USB просто пропасть. Но если есть сомнения, ты можешь получать для каждого кадра TimeStamp и сохранять данные из ком-порта привязанные к нему.
GOGI> Затыки идут в части или в части забрать кадр из памяти или сохранения видео или картинок. Все эти затыки во-первых, отлавливаются программно, во-вторых, их достаточно легко можно избежать.

Еще раз спасибо за подсказки. Будем пробовать. Какой то ответ обещают из Королева.
Поэтапно, со скрипом, но все пока решается.

GOGI> Расстреляйте меня, если на неделе не отправлю.
Ай не надо в меня стрелять! Я почти отправил, даже по конвертам разложил, осталось до почты доехать. В компенсацию такой бесчеловечной задержки в каждой посылке будут не только платы, но и полный комплект деталей хотя бы на один альтиметр. Только контроллеры не прошитые, т.к. я их через Microsd разъем шил прямо на плате.

RLAN> Но. 20МГц полоса ???
RLAN> Как же наносекундные импульсы ловить?
RLAN> Какую схемотехнику использовать?

Схемотехнику уже не помню. Когда-то использовали ЛФД для детектации потоков от частиц облаков Венеры. С наносекундными импульсами. В текущей практике с TEA CO2 использую photon-drag детектор на кристале Ge. И осциллограф (Tektronix) с памятью. С полосой 20 MHz. Какой-то буфер необходим, наверное, для предварительного хранения сигнала. А попробовать можно напрямую, с осциллографом. Я так делал, только с обычным Si ФД, ловя вспышку от кратера.

Поскольку актуальность измерения высоты полёта высока так же, как неадекватно высока и стоимость соответствующих измерительных устройств, решил ускорить темпы разработки собственного БРЭО по этой части.

Просто на место тензодатчика воткнул датчик давления. Нос датчика плотно посадил в отверстие шприца и поигрался на разряжение от одного предела до другого. Получился отличный результат. На тех мощностях, что даёт XMega и алгоритмах усреднения помех вообще не видно ни на всём возможном диапазоне измерений, ни на метровых дистанциях.

Уже почти готов бортовой алгоритм управления ракетой на двухстадиный парашют... Осталось только плату распаять и работу с флешкой освоить...