Jump to content

    

vid435

Участник
  • Content Count

    22
  • Joined

  • Last visited

Community Reputation

0 Обычный

About vid435

  • Rank
    Участник

Контакты

  • Сайт
    Array
  • ICQ
    Array

Recent Profile Visitors

872 profile views
  1. Разрабатываю физический уровень модема G3 PLC спецификация ITU G.9903. Столкнулся с несовместимостью при работе с китами TI G3 PLC Developer Kit, Max2992 Eval Kit и SAM4CP16C-EK. При приеме сигналов с китов, FCH декодируется правильно. Данные с модуляцией BPSK и Robust в дифференциальном и когерентном режиме декодируются со всех китов. QPSK и 8PSK в дифференциальном режиме работает только с MAX, но при этом MAX ставит бит когерентного режима в FCH что противоречит спецификации и чтобы принимать этот сигнал приходится его игнорировать, что не позволяет использовать когерентный режим. Когерентного режима у Maxima нет. При декодировании QPSK и 8PSK с кита Atmel возникают сплошные ошибки декодирования RS, при этом при отличном С/Ш и хорошей синхронизации вижу много точек явно не принадлежащих созвездию. При работе с TI правильно декодируется первый пакет, а все последующие выглядят так же как и с Atmel. Создается впечатление что стандарт и модемы не соответствуют друг другу, ну или я совсем не умею их готовить :-(. Прошивку кита TI обновлял до последней, для остальных как понимаю это невозможно. Сами киты пакеты друг от друга видят но ругаются на разные ошибки, видимо это логично, так как формат пакетов у них разный. Но среди прочих проскакивают ошибки FCH чего быть не должно и даже мой модем их декодирует без ошибок.
  2. Стоимость и условия работы наверно удобнее обсуждать в личной переписке, почта iliya(.)voronov(a)gmail(.)com или по скайпу iliya.voronov
  3. Модемы делались и делаются, например наши разработки можно посмотреть на rfdsp.ru. последние лет десять делали только беспроводные, до этого телефонные тоже. Но сейчас на них нет платежеспособного спроса, да и исходники выложены в сети, правда часто качество декодирование плохое и разбираться в чужом кривом коде сложнее чем самому написать imho. Года три назад со сходной с вами задачей обращался человек из КНИИТМУ тоже нужно было сделать на отечественных компонентах V.32 совместимый с CMX, но дальше разговоров не пошло.
  4. Удаленка возможна и даже приветствуется, но надо встречаться чтобы передать железки, хотя если у исполнителя есть любая плата с 5416 и эмулятор то это не нужно. Хочется получить результат через месяц, хотя реальной работы для того кто этим занимается дней на 7 - 10. Стоимость имеет смысл обсуждать лично. Неоптимизированный код под 54 и код для MSVC это не "двойной код", а один и тот же код, в которым базовые операции типа ADD, MPY, MAC (все это помещается в один h-файл) определены либо через интринсики 54, либо битэкзектные их реализации как функции на стандартном С. Наверно есть три варианта: 1. В случае простых алгоритмов (FIR, свертка, векторные операции) оптимальный C-шный код пишется легко и почти не хуже asm. И это уже во многом сделано. Там правда есть специфическая проблема 54 то что в C нет 40-битных чисел и результаты MAC должен укладываться в 32 бита. 2. Если алгоритмы сложнее (например БПФ) это уже сделать сложнее, и dsplib тут вполне подходит. Хотя я его тоже его не люблю. 3. А вот как оптимально написать Витерби на С я не знаю (может кто-то знает), действительно C-шный код раз в 10 медленнее asm а в нем и тратится большая часть MIPSов. И тут действительно будет два кода - один оптимальный на asm, второй битэкзектный с ним на С неоптимальный 54 и MSVC. Но это и есть основная задача. Надо вписаться в 90 MIPS (имеющиеся 100 МГц процессора минус 10% потери на прерывания, и прочие служебные функции). Для данного модема это вполне достаточно. Конечно у 55 лучше и архитектура процессора и компилятор. Но нужен именно 54XX.
  5. Имеется референсный фикс пойнтовый код. Необходимо оптимизировать по скорости коррелятор, FIR дециматор, Витерби декодер, декодер Рида Соломона, АРУ и др. Объем кода небольшой, корректора канала и обращения матриц нет. Код структурирован, интринсики и другие базовые операции вынесены в отдельные файлы, имеется тестовая среда. Часть функций достаточно будет оптимизировать на C или использовать dsplib, но часть видимо придется переписать на asm. Необходимо сохранить читаемость кода, возможность сборки под MSVC и без оптимизации под 54XX. Среда разработки CCS3.3. iliya.voronov(a)rfdsp.ru 7(916)683-5103 Илья
  6. Цена зависит от массы вещей, присылайте хотя бы предварительное ТЗ, тогда можно будет о чем-то говорить.
  7. Занимаемся радиомодемами/радиопротоколами, проекты можно посмотреть на rfdsp.ru, почта info(at)rfdsp.ru, скайп iliya.voronov, Илья
  8. Разработка на заказ стеков беспроводных протоколов передачи речи и данных, радиомодемов, декодеров радиопротоколов, обработка речи. Реализованные протоколы: TETRA, GSM, DMR, APCO, DVB-T, DRM. rfdsp.ru info@rfdsp.ru
  9. писать на iliya.voronov{гав}gmail.com
  10. А какую производительность требует демодулятор UMTS на ПК? Влезет ли это в реальном времени на не быстрый процессор типа Atom или Celeron? Для упрощения разработки хотелось бы остаться на плавучке, да и оптимизировать на уровне SSE- инструкций тоже не хотелось бы.
  11. С SB начинать неудобно - в SB могут использоваться разные synchronization sequence в зависимости от того используется ли COMPACT мода или нет (а узнать это можно из частоты FB), так что придется считать корреляцию с обоими последовательностями. Ну и конечно, чтобы обнаружить корреляцию со сдвинутым по частоте сигналом придется считать не простую корреляцию, а векторное произведение с референсным сигналом и потом от него FFT. Да и TS 145 10 рекомендует ловить в начале FB, а потом SB и дальше BCCH, где-то была даже блок-схема. А ловить FB когда спектральный ноль совпал с его частотой просто не нужно. Достаточно поймать сигнал лучшей БС с данным MCC MNC (а не _все_ БС, которых может быть видно штук 15 для одного оператора), а дальше БС в system information сообщит о всех БС. А потом, когда засинхронизировались с БС и перешли в dedicated моду и далее - FB действтительно не нужен и его можно игнорировать.
  12. Столкнулся с систематическим кодом, который в стандарте ETSI назван кодом (16,5) Рида Маллера, порождающая матрица выглядит так: 1,0,0,0,0,0,1,1,1,0,1,1,1,1,0,0 0,1,0,0,0,0,0,0,0,1,1,1,1,1,1,1 0,0,1,0,0,1,1,1,0,0,0,0,1,1,1,1 0,0,0,1,0,1,0,1,1,1,0,1,0,1,0,1 0,0,0,0,1,1,1,0,1,1,1,0,0,1,1,0 Это совсем не похоже на классический вид Рида Маллера 1,1,1,1,1,1,1,1 0,0,0,0,1,1,1,1 0,0,1,1,0,0,1,1 0,1,0,1,0,1,0,1 Посоветуйте где прочитать про быстрые алгоритмы его декодирование?
  13. Знания и опыт: - Хорошие теоретические знания в области цифровой обработки сигналов и большой практический опыт разработок для встраиваемых систем - Значительный опыт программирования на C/C++, оптимизации на C и Asm; CCS, DSP BIOS, CSL; MSVC; GCC, Linux и др. - Опыт разработки для: TMS 55XX, 64XX, 54XX, ARM, ADSP-21XX и др. - Выполнение всего цикла разработки: моделирование DSP алгоритмов в MATLAB, создание среды разработки и тестовых векторов для ПК, оптимизация кода для целевого процессора, разработка документации и сопровождение разработок - Хорошо организованный процесс разработки, сжатые сроки, ответственность Выполненные проекты (самостоятельно или в составе команды разработчиков): - Модемы для телефонных линий V.34, V.32 - Факс-модемы: V.29, V.27 - КВ радиомодемы: MIL-STD-188-110A/110B, STANAG 4539 - Вокодеры: G.723, G.729, GSM EFR - Видео декодеры: H.264 AVC, China AVS - Телефонная сигнализация: DTMF, R1/R2, Caller ID - Анализаторы качества электроэнергии: ГОСТ Р 51317.4.30, ГОСТ Р 51317.4.7, ГОСТ 13109 Опыт работы: - 4-х летний опыт разработка DSP алгоритмов и электронных устройств под заказ (freelancer) - более чем 12-ти летний опыт разработок в данной области Более подробная информация о выполненных разработках представлена на http://powerdsp.narod.ru, тел. 8 (916) 683-5103 Илья Воронов
  14. Как я понимаю, смысл применения фурье как раз заключается в том чтобы точно разделить частоты гармоник, интергармоник и субгармоник. Например сигнал в полосе 95 - 105 Гц считать второй гармоникой, в полосе 110 - 140 Гц интергармоникой, в 145 - 155 Гц третьей и т.д. Относительно размеров памяти - действительно для обработки 4-х токов и 4-х напряжений требуется 4 * 2048 комплексных слов и нужнa еще двойная буферизация (чтобы делать вычисления одновременно с накоплением следующих отсчетов) = 32768 слов. Я их хранил во внешней динамической памяти и копировал во внутреннюю для выполнения вычислений FFT. Кстати, за одно комплексное вычислени FFT можно вычислить два FFT для реальных сигналов.