Quasar

В ответ на мое объявление было много предложений готовых модемов (вы я так понимаю тоже предлагаете готовый модем). У меня была задача проще, мне нужен был радио тракт, протокол приема и передачи у меня свой, причем этот же радиотракт я использую и для передачи обычного аналогового голоса с аналоговым сигналингом (CTCSS, DCS, Select5, MDC1200). Как я уже писал, задачу решили, но пока не самым оптимальным способом.

Побороли симптом. Спецификатором static вы переместили эти переменные из стека туда же, где хранятся глобальные переменные. Возможно стек текущей задачи портился другой задачей. Теперь вы текущую задачу от этого защитили, а задача, которая портила ей стек, портит его другой задаче. :-)

А вот RIP и SNMP прям всем нужны. DNS также крайне редко нужен, особенно на легких железках с крайне ограниченными ресурсами. На ПЛИСах, мое наблюдение, нужен чаще всего UDP и большая скорость. Да, такое ощущение, что AlexandrY перечислением всяких умных аббревиатур во многих темах пытаетесь показать свой блистательный ум. STP, RSTP, IGMP, SIP, RTP, RADIUS, WebDAV, BGP, NetBIOS, FTP, HTTP, HTTPS - конечно же все это должно быть в любом приличном стеке и никак иначе! Его считают стеком, и в каждом конкретном случае, инженер сам решает, подходит ему этот стек или нет. Ну а про RTOS это вообще перл. Топикстартеру прежде всего надо определиться, в каком объеме необходима поддержка TCP/IP, какие скорости? Во многих случаях, повторюсь, достаточным оказывается вообще один UDP без TCP в ПЛИСах.

Ссылка стала нерабочей, но все еще актуально. Вот такие

На заводе в Китае, мне китайцы как-то светанули вот такую штуку Она позволяла хранить до 3 прошивок. Какую шить, выбиралось кнопкой. С помощью таких изделий штамповались партии по 1000 - 10000 издели, но увы, интерфейс был только на китайском. СтОяло порядка 100 долларов.

Ой. Вы хотите сказать, что клиенты, находящиеся за NAT'ом, ВСЕГДА слушают ЛЮБОЙ порт? Утилиты есть у многих вендоров, у Apple - AirPort, у D-LINK для их свитчей есть какая-то там утилита и т.д,. Это всего лишь вопрос выбранного пути. "Как у всех" или "не как у всех", тут не причем.

Я сейчас читаю Скляра на английском, там глава третья baseband demodulation/modulation (низкочастотная модуляция /демодуляци) и глава четвертая - bandpass (полосовая модуляция/демодуляция). Честно говоря, меня термин bandpass немного смутил. Я всегда думал, что baseband это комлексная огибающая с несущей около 0, а у Скляра это bandpass.

Я честно говоря не понял. Появление сигнала на выходе, раньше чем на входе, означает отрицательное ГВЗ, но судя по картинкам ФЧХ, её наклон отрицательный, то есть ГВЗ как и положено, положительное и конечное. В общем я не понял ни то, что задержка бесконечна (сигнал ни когда не пройдет) ни то, что она отрицательна (сигнал на выходе появляется раньше чем на входе). Как получили бесконечную или отрицательную задержку?

Я думаю это какой-то неправильный сигнал :-) Скремблирование конечно обязательно, единственно что, при передаче синхро-последовательностей используют только символы +3 и -3, ну оно и понятно.

Схема описанная топикстартером вполне типичная, для приема 4FSK и C4FM, на выходе демодулятора обычная 4PAM последовательность, задача убрать DC, обнаружить центр символа, в определенных пределах подстроить пороги. Можете поглядеть как это сделано в gnu-radio. Я с помощью демодулятора из gnu-radio спокойно принимал APCO P25 и dPMR, хотя конечно как пишут эстеты, подобное надо принимать когерентно.

Приветствую всех, может кто подскажет где купить, или сам продаст немного конденсаторов в Москве: AVX корпус SQCB, номиналы: 1p, 2p2, 3p, 4p7, 6p8, 8p2, 220p. Вот такие

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

Ну вроде теперь все собирается в единую картину. Тут выше писали про точность комплексного гетеродина, точнее про точность сдвига фазу в 90 градусов в I и Q каналах. В этой связи два вопроса. Почему бы не понижать частоту обычным гетеродином, а комплексный сигнал получать уже в цифровом домене с цифровым комплексным гетеродином? Понятно, что повышаются требования к АЦП, частота дискретизации должна быть в два раза выше, но вроде это не сильно страшно. Или есть еще какие-то сложности? И второй вопрос, при получении квадратур в приемниках в цифровом домене используют цифровой комплексный генератор. А возможно ли для этих целей использование фильтра Гильберта, просто дополняя реальный сигнал мнимой составляющей?

Я наверное болел, когда в школе изучали квадратурную обработку ( :-) ), а голые синусы и косинусы на тот момент меня, как радиолюбителя, мало интересовали. Меня собственно сбивает с толку, периодические упоминания в литературе когерентного приема. Очень часто пишется, что при таком способе приема, гетеродин приемника должен быть засинхронизирован с несущей. Но я так понимаю, что это речь идет о несущей уже в baseband'е? То есть, я на своем SDR-USB донгле, который ни как не синхронизируется с несущей, могу когерентно принимать, например, QPSK перенося сигнал в basseband и уже там, софт декодера будет производить синхронизацию и демодуляцию, так?

Да, в донгле есть тюнер E4000: Собственно вопрос, вы хотите сказать, что синтезатор в этой микросхеме синхронизируется с несущей?

Вот этот момент неясен. Провожу эксперимент. Включаю RTL-USB донгл, гетеродин его настраиваю, например, на 434.7 МГц, далее, подаю на вход донгла сигнал от генератора, например, несущая с амплитудной модуляцией синусом частотой AF. Вижу на спектроанализаторе матлаба традиционный спектр АМ. Несущая на частоте 0 Гц, и две боковые. Одна боковая на частоте -AF, другая +AF. Начинаю на генераторе крутить частоту несущей, спектр сигнала на спектроанализаторе просто двигается, форма его не меняется, хотя гетеродин квардратурного смесителя уже даже не на частоте несущей. Ни каких зеркалок не наблюдаю. Никакой обработки по факту нет, просто квадратурные отсчеты подаю на компонент Spectrum Analyzer. Внутри RTL-USB донгла - вот такой чип, переключенный в режим выдачи IQ отсчетов http://www.realtek.com.tw/products/product...&ProdID=257

Приветствую. Решил по изучать квадратурную обработку сигналов, читаю Ричарда Лайонса и материалы dsplib.ru и не могу понять для себя следующее. Что более или менее ясно: - Есть комплексные сигналы, которые представлены реальной и мнимой частью. Спектр таких сигналов как отрицательный, так и положительный, симметричный или нет; - Есть сигналы аналитические, это комплексные сигналы, спектр которых имеет всплески только в положительной части, в отрицательной нет; - Есть сигналы реальные, спектр которых симметричен. Для перехода от реального сигнала к аналитическому (то есть комплексному с положительным спектром) используют преобразование Гильберта, а при переходе от аналитического к реальному просто откидывают мнимую часть, её и передают по эфиру. Что мне не ясно: При приеме сигнала от антенны, он чисто реальный, но какой он после обработки квадратурным смесителем? IQ сигнал == комплексный или нет, то есть такой сигнал подчиняется всем правилам обработки комплексных сигналов или нет? В Matlab с помощью rtl-usb донгла я принимаю реальный эфир, с донгла идут квадратурные отсчеты, если я подключу к выходу донгла Matlab'овский спектро-анализатор, то увижу там несимметричный спектр, то есть сигнал комплексный аналитический? Или нет? Должен ли квадратурный смеситель обязательно быть за синхронизирован с точностью до фазы с несущей (I канал) или нет? Вопрос навеян самим терминов In-phase.

По-моему это самый логичный вариант. Веб-морда и все скрипты лежат в основном приложении, не сжирается место в загрузчике, не усложняется процесс обновления переустановкой соединения. На неустойчивой сети это может вызвать проблемы. Если бы у меня была SD карта, я бы сделал так: 1) Страничка загрузки лежит в основной прошивке; 2) С её помощью пользователь загружает фаил прошивки на SD карту, основная прошивка проверяет целостность и если все ok, прыгает в бутлоадер; 3) Бутлоадер, обнаружив новое ПО на карте, начинает его прошивать (расшифровывать и прошивать?), после чего передает прошитому ПО управление, можно еще где-нибудь в ОЗУ оставить флаг статуса последнего обновления, для того, что бы пользователь в веб-морде увидел, что все ok (или не ok); 4) Пока все это происходит, на веб-странице горит прогресс бар (просто таймер на примерное время обновления), после того, как таймер истекает, JavaScript начинает пытаться обновлять страницу, дабы узнать статус.

Ваш бред с Wi-Fi AP и DHCP сервером на железке тоже и что же теперь? Я рассказал как сделал я, а вы лишь теоретизируете как можно. По поводу создания веб-странички для загрузки ПО хочешь с WebSocket, хочешь стандартными AJAX средствами с POST запросом особо обсуждать нечего, бери и делай. Ну придется немного с http/html/JavaScript разобраться, ну и все собственно.

Ну да, вы даже не поняли, что Java это не средство разработки.

То есть начали с того, что пользователь не может IP поменять, а теперь домохозяйка, решившая обновить вашу железку, должна решать вопрос с Safari? Или ставить другой браузер? Или делать джеил? Или переходить на андроид? Вы очень последовательны и логичны в рассуждениях. Ладно, я понял, что вы не знакомы с технологией Java (раз спрашиваете о перекомпиляции), и будете как и древние люди, доказывать, что все это черти, бесы и от лукавого. Но по-моему, это не является предметом данного треда.

Не на паре, а на тройке, еще раз Win, Lin, Mac и проблем с обновлялкой не было. А неуверенность в голосе, потому что я про вас говорю (ну или про кого-то еще, кто будет реализовывать обсуждаемый мною подход) и соответственно уверенности в действиях этого человека у меня нет. То есть: Так что просьба не передергивать, я реализовав метод обновления с помощью Java обновлялки с проблемами не столкнулся, как получится у вас, не знаю :-) [off] На IOS не работает! Сафари умеет грузить только картинки! Юзер останется недоволен :smile3046: [/off]

Ну вообще как бЭ да, перекомпилировать Java приложение не надо. Тестировать конечно надо, но при правильном дизайне, ведет себя приложение одинаково на всех платформах. Могут возникать некоторые вопросы по Linux'у, так как там частенько используют свободную JRE, а не JRE от Sun, а она глючноватая немного. Но это тоже решаемо, и в основном встречается на сложных приложениях. На простой обновлялке вы вряд ли столкнетесь с этим. А вот если юзать QT с C++, то конечно, здесь нужна сборка под каждую платформу. На iOS нет Java, на Android Java не от Sun. Мы говорим про десктоп, Win, Lin, Mac. Я одинаково много работаю на всех этих платформах и могу сказать, что Java чрезвычайно кроссплатформена. На IOS вам с трудом удастся загрузить фаил прошивки через Web, так что здесь вариант обновления через Web тоже не покатит. А Android можно вообще выкинуть из рассмотрения, кому придет в голову обновлять железки с него (да и с IOS в общем-то тоже)?

Нет, я со всем ознакомился и недоумеваю в связи с предложениями поднимать DHCP на железке или еще где-то (на хосте). Фиксированный IP возможен только в локальной сети, там, где как вы отметили выше, возможна работа вообще без IP. Можно использовать DHCP с полем file (или еще каким, указывающим адрес хоста с прошивкой), что бы при первом запуске железка качала ПО. Но я с трудом представляю себе ситуацию, когда первый запуск железки, происходит только с бутлоадером, без основной прошивки, соответственно без какой-то начальной или уже установленной пользователем сетевой конфигурации. Плюс, если железка стоит не в одной локальной сети с пользователем, то фокус с DHCP опять не получится и возвращаемся опять в начало, нафига нам IP со всеми этими страшными аббревиатурами? 1) Железка приходит к пользователю уже с какой-то прошивкой; 2) Он обнаруживает, что прошивка устарела (перед этим настроив железку, то есть вбив сетевую конфигурацию); 3) Начинает обновлять, соответственно при обновлении надо использовать ту конфигурацию, которую он установил в п. 2. Когда доступен только загрузчик, это обычно аварийный режим восстановления, требует чаще всего работы пользователя и железки в одной локальной сети. Поэтому мне не ясен вот такой посыл: Поэтому, я бы топикстартеру все-таки порекомендовал поглядеть в сторону утилиты обновления, которая ищет и обновляет железки в локальной сети (то есть железки с неизвестной сетевой конфигурацией) и обновляет железки где угодно с известной сетевой конфигурацией. В плане кроссплатформенности, не нравится Java, берите C++ с QT. Обновление через Web на 48КБ, сделать конечно можно, тем более если у вас есть SD карточка, но в этом случае автопоиск железки в сети невозможен, надо знать её IP.

Что-то вы тут все усложняете со своими IP адресами. Железка до обновления на каком-то IP уже сидела? И, наверное, работала? Вот на нем пусть и обновляется. Первый запуск и первая прошивка она всегда с каким-то статическим заводским IP, и шьется на производстве специальным человеком. Задача как я понимаю обновить уже где-то работающую железку. У меня все железки обновляются по ethernet'у. Там, где ресурсов мало, я использую загрузчик на uIP с TCP и http. http используется только как протокол передачи, а в качестве интерфейса обновления использовал самописную программу на Java. То есть, пользователь запускает программу обновления, вбивает в ней IP железки, которую хочет обновить и ждет секунд 30, прогресс бар в программе пишет сколько процентов загрузилось. Поскольку программа обновления написана на Java, она полностью кроссплатформенная, запускается на Win, Lin и Mac. Кто-то скажет, что у Java есть недостаток в виде java машины, но сейчас у многих производителей ПО Java популярна, и Java машина у многих пользователей уже есть, если же её нет, то не проблема её поставить в эпоху мегабитов и мегабайтов :-) Второй вариант, который я использую, на жирных железках (с embedded linux), это использования Web морды, то есть, пользователь заходит на веб-морду, загружает через Web интерфейс прошивку, получив фаил прошивки, железка его расшифровывает, разархивирует, обновляет rootfs, обновляет ядро (если оно есть в прошивки), обновляет uboot (если оно есть в прошивки). При этом флеш разделена на две равные части, Раздел 1 и Раздел 2, если сейчас все ПО запущено с Раздела 1, то обновляется ПО на разделе 2 и наоборот. При перезагрузке, просто переключается загрузочный раздел со старого на вновь обновленный. Соответственно, если в процессе обновления произошел сбой, ничего не поломается, так как с текущим разделом никто, ничего не делал, железка как запускалась с него, так и будет это делать дальше. Естественно, все прошивки я шифрую во избежание их модификации супостатами, но это уже другая тема :-)