06.09.2011, Исследование машины быстрого поиска в НИИ КП
Материал из SRNS
Korogodin (обсуждение | вклад) |
Korogodin (обсуждение | вклад) (→Обсуждение) |
||
| (не показаны 6 промежуточных версий 1 участника) | |||
| Строка 4: | Строка 4: | ||
* Реализовать на ARM алгоритм слепого поиска с минимальным требуемым временем на прохождения поля поиска | * Реализовать на ARM алгоритм слепого поиска с минимальным требуемым временем на прохождения поля поиска | ||
* Оценить время работы такого алгоритма при нахождении сигналов уровня 20 дБГц. | * Оценить время работы такого алгоритма при нахождении сигналов уровня 20 дБГц. | ||
| + | |||
| + | Предполагается, что алгоритм будет некоторым аналогом когерентно-некогерентного ячеестого накопления. Откуда ему будут соответствовать время когерентного накопления <math>T_{coh}</math> и некогерентного накопления <math>T_{nocoh}</math>. Ожидаются рабочие значения <math>T_{coh} = 9 ms</math>, <math>T_{nocoh} = 5 s</math>. Желательно получить время прохождения поля поиска менее <math>T_{coh}/2</math>. | ||
== Входные данные == | == Входные данные == | ||
| Строка 11: | Строка 13: | ||
[[File:20110906_SxemaFormirovaniyaIQ.png|center]] | [[File:20110906_SxemaFormirovaniyaIQ.png|center]] | ||
| + | == Ограничения == | ||
| + | |||
| + | В реальности доступной памяти - около 1 Мб. Но если алгоритм не ограниченный данным условием покажет неудовлетворительное время поиска - этого будет достаточно для отказа от идеи использования ARM'а в качестве машины быстрого поиска. | ||
| + | |||
| + | Вероятно, в боевом варианте нельзя пользоваться сторонними библиотеками. | ||
| + | |||
| + | == Обсуждение == | ||
| + | |||
| + | См. обсуждение в [[Blog_talk:Korogodin/06.09.2011,_Исследование_машины_быстрого_поиска_в_НИИ_КП|комментариях]]. | ||
{{wl-publish: 2011-09-06 12:32:11 +0400 | Korogodin }} | {{wl-publish: 2011-09-06 12:32:11 +0400 | Korogodin }} | ||
Текущая версия на 09:11, 9 сентября 2011
Содержание |
[править] Задача
- Реализовать на ARM алгоритм слепого поиска с минимальным требуемым временем на прохождения поля поиска
- Оценить время работы такого алгоритма при нахождении сигналов уровня 20 дБГц.
Предполагается, что алгоритм будет некоторым аналогом когерентно-некогерентного ячеестого накопления. Откуда ему будут соответствовать время когерентного накопления 
и некогерентного накопления 
. Ожидаются рабочие значения 
, 
. Желательно получить время прохождения поля поиска менее 
.
[править] Входные данные
- Сигнал С/А GPS: +/- 5 кГц по частоте, +/- 512 чипов по ПСП + легкая модификация под ГЛОНАСС СТ
- Алгоритм берет данные из двух буферов по 128 слов. Буферы заполняются попеременно. Схема формирования данных для ячеек буфера:
[править] Ограничения
В реальности доступной памяти - около 1 Мб. Но если алгоритм не ограниченный данным условием покажет неудовлетворительное время поиска - этого будет достаточно для отказа от идеи использования ARM'а в качестве машины быстрого поиска.
Вероятно, в боевом варианте нельзя пользоваться сторонними библиотеками.
[править] Обсуждение
См. обсуждение в комментариях.
[ Хронологический вид ]Комментарии
К чему это? В НИИ КП задание дали?
Да, Жень. И так как мне не хочется изобретать велосипед, надеюсь у тебя проконсультироваться на эту тему. Дооформлю тут всё и пришлю тебе письмо.
Ты поясни, они там что, программно в ARM быстрый поиск устроить хотят? Сразу предупреждаю, я тут прикинул, текущая реализация блока поиска в Альпаке для обеспечения требуемых характеристик будет искать, видимо, 3 часа. У тебя ресурсы существенно скромнее. Поиск в микросхеме Шувалова должен быть намного быстрее - 320 с. Поиск в нынешнем SiRF'е - 2.5 с, но это, скорее всего, не так.
Ты абсолютно прав.
Вот поэтому я не верю в программный поиск. Кстати, про Альпаку, возможно, написано неверно - я тут недавно подкрутил поиск, и он стал искать в несколько раз быстрее. Надо померять. Но это всё равно будут десятки минут.
Из скидок у меня только простота сигналов - С/А и СТ.
Помнится у Саши был какой-то хитрый алгоритм поиска в программном приемнике, основанный на перемножении спектров.
Эти ограничения - десятки минут, они вызваны возможностями процессора? Или связки какой-то аппаратный поиск в ПЛИС + дополнительная обработка процессором? Как эти цифры привязать к чисто программному поиску?
Это как раз у меня был этот хитрый алгоритм, он сейчас заложен в Альпаку. Оценки выше приведены для сигнала GPS C/A, для ВТ всё будет пропорционально хуже. Памяти 1 Мб немного, требуемый объём памяти можно разменять на время поиска. Ограничения вызваны обработкой в процессоре. В ПЛИС можно делать быстрее, но нужна куча ресурсов, это одна из причин, по которой нужно делать новую Альпаку.
В поиске всё вообще всегда в ресурсы упирается.
Может быть, перенести сюда наше обсуждение по почте? А то потеряется...
Сделано
Войдите, чтобы комментировать.