16 бит это уже серьезно. Не думаю, что программные демодуляторы, написанные годами ранее, способны "почувствовать" такую точность. Здесь можно ждать улучшений.
Это проверенно? У меня был случай когда не повышало. Перешел с типа float на double в программе на C++, а там еще повышать и повышать. Шум складывается с сигналом, а не стирает сигнал. За достаточное время "сумма" шума равна нолю, сигнала нет. Но вот квантование - не шум. Это помеха. Понимаю еще спор о 24битах и 32битах, но 12 (при современных технологиях) явно мало.
Чем точнее будет измерен сигнал, тем точнее он будет восстановлен. Такова природа шума - сколько раз он увеличит амплитуду на разных отсчетах столько и уменьшит на других, но для точного вычитания нужны точные отсчеты. Например при когерентном накоплении сигнал с каждым отсчетом увеличивает амплитуду пока не сработает детектор, шум при этом то увеличивает, то уменьшает сигнал. Но за достаточное время сигнал "вылезает из-под шума". Если только АЦП чувствителен к очень малой амплитуде сигнала, а это разрядность(при малой разрядности тоже сработает, но ждать надо дольше).
В остальных системах принцип тот-же. Это основа - не измеришь, не получишь. Если частота дискретизации важна для приема широкополосных сигналов(и разрядность тоже), то для узкополосных остается разрядность.
Давайте отдельно - Мгц и биты. Это немного разные сущности. Первое время, второе амплитуда и они ортогональны. 24 бита берут в звуковой карте, но это уже ZeroIF архитектура.
И все же, если уровень шума выше уровня сигнала, поможет ли более высокоразрядный АЦП?
Поможет. Давно уже передают "под шумами".
А если он не совсем случайный?
Тогда применяют избыточность - кодирование с восстановлением. При этом аналоговый сигнал самый избыточный и точность здесь играет решающую роль.
У KiwiSDR концепция
Концепция не нарушается. Здесь же не предлагается вырезать, только ослабить, как раз для соблюдения "концепции" - принимать все волны , а не только сильные.
Понятие "любительская связь" не оправдывает термины "довольно слабый", "сильно хуже". Лучше этого избегать, но я Вас понимаю. Что касается разрядности попробую объяснить проще:
АЦП измеряет сигнал вместе с шумом. Шум считается случайным, он может как увеличить сигнал, так и уменьшить. При интерполяции (сверхдискретизации) сигнал восстанавливается и при этом шум вычитает сам себя. Например два соседних отсчета шум "поднял" - средний(восстановленный) также поднят и ошибочен. Но если добавить отсчет по середине(по амплитуде) он должен быть меньше в силу природы шума и сигнал будет восстановлен точнее. При аналоговом сигнале это позволит точнее настроится на несущую (поднесущую) и получить например стерео или вообще факт наличия сигнала. При цифровом правильно принять бит и т.д.
Что касается мощных вещательных станций - резать(ослаблять) фильтром. Это достойный компромисc даже для чистого SDR. Вещание явление не случайное и очень продолжительное и снижать чувствительность из-за него неразумно.
(радиолюбительский прием) то там 99% всех сигналов это различные "аналоги" типа AM/FM/USB/LSB
А теперь к спору: именно так. Первое с чем Вы столкнетесь, пытаясь повысить точность синхронизации - разрядность АЦП. От точности синхронизации зависит чувствительность(сейчас говорят производительность канала) при выделении известного сигнала. От разрядности АЦП - чувствительность(изменения, а не только диапазон) вообще. Если изначально изменения вызванные полезным сигналом будут незначительные из-за шага квантования АЦП, то принять такой сигнал будет невозможно. Из тех расчетов которые я видел - 14 бит это минимум при современной возможности обработки сигнала. Тем более SDR.
SDR тем и отличается, что в нем можно применять программные(последние изученные и лучшие) методы синхронизации. А здесь все "обрезается" на входе. Наша задача - "вытащить сигнал из под шумов".
Конечно, 12 бит хуже, чем 14 или 16, но я посчитал, что в сильно зашумленном эфире города нет великого смысла гнаться за разрядностью АЦП.
Все ровно наоборот. Чем ниже соотношение сигнал\шум, тем выше должна быть разрядность, точность установки частоты, синхронизация по частоте, фазе и времени. Самая главная задача при приеме - как можно точнее вычислить параметры передатчика - частоту, фазу, частоту дискретизации и фазу её. Проверить довольно просто на стенде - соединить передатчик и приемник с добавлением шума и помехи. Определить минимальное отношение сигнал\шум. Затем использовать один задающий генератор для передатчика и приемника(абсолютная синхронизация). Обнаружиться, что очень есть ешё куда ползти. Объясняется все просто принципом суперпозиции. Какой бы ни был шум - сигнал в нем есть.
Более серьезные производители - 30м. Еще больше верим.
Исследователи этих устройств - 30футов. Безусловно верим.
Это и есть постановка задачи. Добиться приема при минимальном соотношении сигнал\шум. И лучше это делать с SDR. Что касается "поверх IEEE802.15.4" - стандарт не определяет. Можете передавать что угодно, прописаны только условия MAC доступа к среде.
И снова - это развивающийся проект. В стандарте 2020 года уже 19 видов модуляции. Возможно есть все прошивки на nrf52840 или аналогичных устройств, здесь выбрана технология SDR.
Не добавил потому, что эксперимент проводился и с PlutoSDR, и с AirSpy, и с SdrPlay ... C RTL-SDR не вышло, не тот диапазон. Конечно все это с githab не скачано. На githab выложен проект который развивается. Кстати WireShark ничего интересного не покажет - это MAC уровень и там шифрование. Здесь уровень PHY.
Расчет довольно простой. 16мкс - это ±31,25кГц ( 1/16(мкс)). При таком отклонении вектор сравниваемого сигнала повернется от -pi до +pi. Теперь берем ±40ppm и 2.4ГГц - получим 99,6кГц. Отклонение допустимое стандартом в этом диапазоне в три (с лишним) раза больше. Вот на эти три с лишним и делим. В итоге 5мкс.
Согласен. Надо еще и википедии поправить: «OFDM (англ. Orthogonal frequency-division multiplexing — мультиплексирование с ортогональным частотным разделением каналов) является цифровой схемой модуляции...»
Нет. Ни на SDRplay, ни на других устройствах, реализации DVB-T2 я не нашел, а искал довольно тщательно, т.к. задачача первоначально стояла другая.
Версии «для пользователей» не планируется. Возможно более подробное описание, но это будет зависить от популярности.
Здесь речь не о принципиальной реализуемости, а о возможности широкого применения. Сейчас и в бытовой и профессиональной аппаратуре, как правило, Linux на борту и процессор общего назначения. Именно это позволило новым протоколам получить широкое применение. Конечно можно считать «прошивку» устройства не совсем SDR, но здесь грани уже стерты.
16 бит это уже серьезно. Не думаю, что программные демодуляторы, написанные годами ранее, способны "почувствовать" такую точность. Здесь можно ждать улучшений.
Это проверенно? У меня был случай когда не повышало. Перешел с типа float на double в программе на C++, а там еще повышать и повышать. Шум складывается с сигналом, а не стирает сигнал. За достаточное время "сумма" шума равна нолю, сигнала нет. Но вот квантование - не шум. Это помеха. Понимаю еще спор о 24битах и 32битах, но 12 (при современных технологиях) явно мало.
Чем точнее будет измерен сигнал, тем точнее он будет восстановлен. Такова природа шума - сколько раз он увеличит амплитуду на разных отсчетах столько и уменьшит на других, но для точного вычитания нужны точные отсчеты. Например при когерентном накоплении сигнал с каждым отсчетом увеличивает амплитуду пока не сработает детектор, шум при этом то увеличивает, то уменьшает сигнал. Но за достаточное время сигнал "вылезает из-под шума". Если только АЦП чувствителен к очень малой амплитуде сигнала, а это разрядность(при малой разрядности тоже сработает, но ждать надо дольше).
В остальных системах принцип тот-же. Это основа - не измеришь, не получишь. Если частота дискретизации важна для приема широкополосных сигналов(и разрядность тоже), то для узкополосных остается разрядность.
Давайте отдельно - Мгц и биты. Это немного разные сущности. Первое время, второе амплитуда и они ортогональны. 24 бита берут в звуковой карте, но это уже ZeroIF архитектура.
Поможет. Давно уже передают "под шумами".
Тогда применяют избыточность - кодирование с восстановлением. При этом аналоговый сигнал самый избыточный и точность здесь играет решающую роль.
Концепция не нарушается. Здесь же не предлагается вырезать, только ослабить, как раз для соблюдения "концепции" - принимать все волны , а не только сильные.
Понятие "любительская связь" не оправдывает термины "довольно слабый", "сильно хуже". Лучше этого избегать, но я Вас понимаю. Что касается разрядности попробую объяснить проще:
АЦП измеряет сигнал вместе с шумом. Шум считается случайным, он может как увеличить сигнал, так и уменьшить. При интерполяции (сверхдискретизации) сигнал восстанавливается и при этом шум вычитает сам себя. Например два соседних отсчета шум "поднял" - средний(восстановленный) также поднят и ошибочен. Но если добавить отсчет по середине(по амплитуде) он должен быть меньше в силу природы шума и сигнал будет восстановлен точнее. При аналоговом сигнале это позволит точнее настроится на несущую (поднесущую) и получить например стерео или вообще факт наличия сигнала. При цифровом правильно принять бит и т.д.
Что касается мощных вещательных станций - резать(ослаблять) фильтром. Это достойный компромисc даже для чистого SDR. Вещание явление не случайное и очень продолжительное и снижать чувствительность из-за него неразумно.
Там мечтают о 24 битах.
Не туда
Забыл сразу добавить. Работа замечательная.
А теперь к спору: именно так. Первое с чем Вы столкнетесь, пытаясь повысить точность синхронизации - разрядность АЦП. От точности синхронизации зависит чувствительность(сейчас говорят производительность канала) при выделении известного сигнала. От разрядности АЦП - чувствительность(изменения, а не только диапазон) вообще. Если изначально изменения вызванные полезным сигналом будут незначительные из-за шага квантования АЦП, то принять такой сигнал будет невозможно. Из тех расчетов которые я видел - 14 бит это минимум при современной возможности обработки сигнала. Тем более SDR.
SDR тем и отличается, что в нем можно применять программные(последние изученные и лучшие) методы синхронизации. А здесь все "обрезается" на входе. Наша задача - "вытащить сигнал из под шумов".
Все ровно наоборот. Чем ниже соотношение сигнал\шум, тем выше должна быть разрядность, точность установки частоты, синхронизация по частоте, фазе и времени. Самая главная задача при приеме - как можно точнее вычислить параметры передатчика - частоту, фазу, частоту дискретизации и фазу её. Проверить довольно просто на стенде - соединить передатчик и приемник с добавлением шума и помехи. Определить минимальное отношение сигнал\шум. Затем использовать один задающий генератор для передатчика и приемника(абсолютная синхронизация). Обнаружиться, что очень есть ешё куда ползти. Объясняется все просто принципом суперпозиции. Какой бы ни был шум - сигнал в нем есть.
Постановка задачи:
Производители устройств ZigBee(и аналогичные) утверждают дальность приема 300м (прямая видимость). Верим.
Более серьезные производители - 30м. Еще больше верим.
Исследователи этих устройств - 30футов. Безусловно верим.
Это и есть постановка задачи. Добиться приема при минимальном соотношении сигнал\шум. И лучше это делать с SDR. Что касается "поверх IEEE802.15.4" - стандарт не определяет. Можете передавать что угодно, прописаны только условия MAC доступа к среде.
И снова - это развивающийся проект. В стандарте 2020 года уже 19 видов модуляции. Возможно есть все прошивки на nrf52840 или аналогичных устройств, здесь выбрана технология SDR.
Не добавил потому, что эксперимент проводился и с PlutoSDR, и с AirSpy, и с SdrPlay ... C RTL-SDR не вышло, не тот диапазон. Конечно все это с githab не скачано. На githab выложен проект который развивается. Кстати WireShark ничего интересного не покажет - это MAC уровень и там шифрование. Здесь уровень PHY.
Не сбивайте меня с пути истинного. Какое железо? Это SDR!
Расчет довольно простой. 16мкс - это ±31,25кГц ( 1/16(мкс)). При таком отклонении вектор сравниваемого сигнала повернется от -pi до +pi. Теперь берем ±40ppm и 2.4ГГц - получим 99,6кГц. Отклонение допустимое стандартом в этом диапазоне в три (с лишним) раза больше. Вот на эти три с лишним и делим. В итоге 5мкс.
Версии «для пользователей» не планируется. Возможно более подробное описание, но это будет зависить от популярности.
Это моя первая статья. Была…