Конечно же, OFDM подходит для передачи по воздуху, в литературе описано множетство методов компенсации эффектов, связанных с каналом передачи, в том числе и переотражений (т.н. эквализации). Одна из базовых причин использования OFDM и состоит в возможности сравнительно простого компенсирования последствий многолучевого распространения («эха»). Базовый эквалайзер в частотной области (least squares, one-tap) настолько простой, что эквализация в частотной области может легко использоваться и при приеме сигналов с одной несущей (Single-Carrier Frequency Domain Equalization ).
В частности, OFDM используется в Wi-Fi (есть даже открытая реализация, github.com/jhshi/openofdm) в LTE (совместно с SC-FDM) и, наверное, вообще почти везде.
Однако, прочитав статью, я для себя понял, что пользоваться вот этим всем нельзя. Ерунда получается. Хотят высокоуровневый язык, чтоб «не думать», но не получается: то тут галочку в настройках нужно поставить то тут снять, потом проверить в неллисте, что получилось, если получилось плохо, то переделывать… Ну и смысл в этом какой?
Верификация проще, если доверять синтезу в САПРе, а также использовать стандартный интерфейс (я думаю, все поддерживают AXI), то можно верифицировать модуль на уровне матлаба или С. Что гораздо быстрее и не требует покупки Questasim/VCS. В матлабе, конечно, такая функциональность тоже дорогая (я думаю, все равно не дороже САПР от Cadence/Mentor), а вот в случае других HLS, верификация на С будет сравнительно быстрой и дешевой.
Никакой высокоуровневый язык не сможет автоматически поставить регистры в логических функциях так, как это бы сделал инженер. Просто потому, что в чистом языке типа C++ этой информации нет. Компилятору нужны какие-то дополнительные настройки, но лучше бы эти настройки вписывать по месту прямо в код программы (но тогда получится Verilog/VHDL).
На мой взгляд, с помощью C-подобных высокоуровневых инструментов можно с некоторой осторожностью описывать модули в которых данные двигаются только вперед.
Говорят, что Simulink -> System Generator -> Intel/Xilinx позволяет делать что угодно, причем моделировать можно на уровне симулинка, что опять же попроще, чем в RTL. Разбираться с настройками придется и в САПР для верилога тоже.
Около 4-5 лет назад довольно активно использовал Xilinx HLS, если руку набить, то модули получались по качеству сравнимыми с аналогами, написанными на верилоге, так что инструмент вполне рабочий. Но у него, как и у решения Альтеры есть большой минус — зависимость от вендора ПЛИС, что ограничивает переиспользование кода. Опять же, я не заметил сильной экономии времени в масшабах всей разработки устройства. Да, первая версия IP блока появляется в 3 раза быстрее, но для получения производительности, сравнимой с ручным кодированием на hdl, нужно было потратить сравнимое время.
Есть хорошие инструменты, которые должны работать с разными целевыми архитектурами — такие как маршрут Simulink-System Generator-Intel/Xilinx, а также платформо-независимые среды Mentor Catapult или Cadence Stratus, но их использование пока ограничивается еще и стоимостью.
У высоких частот есть значительный плюс — возможность дополнительно разносить каналы связи с различными пользователями в пространстве.
Во－первых, раз сигнал гасится стенкой, значит в каждом магазине в большом ТЦ можно поставить по базовой станции, которые не будут друг другу мешать.
Во－вторых, массовое применение бимформинга со временем позволит использовать одни и те же частоты разным абонентам даже с одной станцией, при этом станция будет их разделять как раз за счет бимформинга.
Самое приятное, что неудобства временные (надеюсь) а улучшать связь потом можно будет годами за счет совершенствования модемов и антенн.
Судя по https://www.disk91.com/2015/news/technologies/one-day-at-sigfox/ у сигфокса полоса в обратном канале 600Гц, при такой полосе стандартные приемопередатчики обеспечивают чувствительность около -130дБм, что, конечно, не -140-150, которые узкополосные сети обещают в аплинке, но тоже вполне себе UNB. Никакого QAM.
Можно поставить ТСХО получше и сделать настолько узкую полосу, насколько получится. Можно поступить как Гудван, и это тоже, по-моему, не противоречит стандарту, тем более, что скорее всего sx-12xx вполне смогут передать bpsk в аплинк.
Во-первых, хорошо, что мы поняли друг друга. «Краем» он зацепится в том смысле, что 30%, наверное, где-то около предела.
Во-вторых, понятно, что приемник должен работать в том режиме, который позволяет его ТСХО. Странно было бы делать входной фильтр 100 гц при работе от кварца. Для дешевой системы входной фильтр нужно иметь в десятки килогерц.
В-третьих, не знаю, причем тут спектральная плотность, какая плотность у обсуждаемой bpsk можно легко нагуглить. Дальность связи можно оценить, посмотрев в документации, какая чувствительность у используемого «конкретного радиотрансивера» в используемом режиме. Я не спорю, что устройства, близкие к границе уверенного приема UL (который, к тому же, может работать на значительно более низких скоростях) такой DL не услышат, по-моему, это очевидно.
Заодно, кстати, можно отправлять такой DL в полосе, где ограничена плотность мощности.
Frequency Separation доходит до 30% ширины входного фильтра.
Дальность при этом понятно какая будет, wide area будет не слишком wide, но мы здесь обсуждаем удаленное обновление и скорость 25600.
Издеваетесь? Я имею в виду ровно то, что и сказал. Зная параметры ТСХО, можно определить неопределенность несущей и выбрать ширину полосы сигнала раза в 3-4 шире, тогда с высокой вероятностью приемник захватит сигнал, возможно, что длины преамбулы даже хватит для полной компенсации ошибки частоты.
Олег, я вроде данный стандарт не упоминал. Можно считать, что я про SigFox.
Понятно, что не зная диапазон частот устройство не сделать.
Видимо, предполагается, что диапазоны частот будут описаны где-то отдельно, типа частотного плана конкретной страны или конкретного вендора БС. (у ЛоРаВан же частоты для разных стран в отдельном документе описаны?)
По DL согласен, там даже скорость описана как «В зависимости от реализации конкретного радиотрансивера», то есть не имея доступа к этому самому трансиверу остается только догадываться, что прилетит от БС в ответ (может, QAM-256?).
С другой стороны, что в этом такого? У устройств разных производителей может быть одинаковый UL (в соответствии со стандартом) и разный DL, под конкретные БС и/или конкретные требования со стороны самого устройства, какие-то базовые станции (более дорогие?) будут поддерживать несколько разных режимов DL.
Наверное, производитель устройств в состоянии узнать у производителя БС, какой там радиотрансивер используется?
К тому же, это дает полную свободу тем, кто будет делать устройство + БС самостоятельно, нет проблем хоть SX-12xx поставить на обратный канал. ( примерно как Гудван, да?)
Принять несколько десятков медленных bpsk сигналов одновременно на нынешнем уровне развития техники вряд ли технически сложно. Другое дело, что Олег довольно обоснованно не видит экономического смысла кому-то изобретать велосипед еще раз, потому что для создания БС как минимум нужно разработать еще и плату + корпус + ПО верхнего уровня и тому подобные вещи, не являющиеся чем-то уникальным, но необходимые.
Я думаю, что для распространения технологии производства БС провайдерам UNB можно было бы предлагать приемники как IP для встраивания в имеющееся железо и популярные отладочные, макетные платы и всякие SDR на различном популярном железе.
Если не гнаться за лучшей достижимой чувствительностью, то простой приемник с полосой килогерц 20-25 можно сделать на чем угодно, упростив декодирование.
В конце концов, SemTech же предлагает чипы для создания станций. Понятно, что аналог SX1301 сделать будет слишком дорого, но выпускать IP с адекватной защитой от копирования вполне можно было бы.
Зная, какой там ТСХО, можно, наверное, той же алгеброй посчитать, какая должна быть полоса для обратной передачи, чтобы точно попасть хотя бы краем и приемник зацепился.
То есть обратный канал станет шире и быстрее от плохих ТСХО, от кварца работать не будет. Справедливости ради, ЛоРа тоже на полосах уже 125кГц требует ТСХО, так что ничего неожиданного.
Я про конкретный 25600 — быстрый режим с широкой полосой, так-то у ЛоРы есть другие плюсы, например возможность замедлиться до 300бит/с без ТСХО. Ну и главное — серийные приемопередатчики для конечных устройств, которые всё это могут.
Со стороны БС-то вполне можно принять bpsk не хуже, чем ЛоРу.
В той БС, что на фото, и корпус недешевый, и raspberry. Это вариант явно более навороченный, чем микроконтроллер + SX1301. Дешевых, как я и писал, пока нет.
Он обеспечивает чувствительность до -137, что позволяет сделать нормальный обратный канал, сравнимый со стандартной LoRa.
Если ориентироваться на -130, то выбор очень широк.
Сложность в том, что на стороне БС должен быть хороший алгоритм и протокол взаимодействия устройства и БС для оценки расхождения их генераторов. То есть опять это будет какая-то секретная часть. А само устройство-то может быть сколь угодно простым.
Радиотракт-то, наверное, сложнее. ПЛИС или DSP можно и в TQFP корпусе найти, отладочную плату взять на первое время и т. д.
Сложность в алгоритмах и прошивке, которые, соответственно, закрыты и/или под патентами.
Собственно, LoRa тоже вся под патентами, а производитель приемопередатчиков вообще один. Я думаю, она настолько внешне открыта потому, что модуляция в ней нестандартная, и в обход Семтека сделать устройство на LoRa нереально: во-первых, модуляция под патентами, во-вторых, сделать нестандартный интегральный приемопередатчик еще (значительно) более сложно, чем базовую станцию UNB.
UNB же использует серийную элементную базу, поэтому авторы технологий сохраняют базовые станции за собой. Зато SigFox'у или Стрижу/Вавиоту можно отправить сообщение почти с любого серийного приемопередатчика.
UNB обеспечивает приблизительно те же скорости обмена данными, что и LoRa, при примерно одинаковых внешних условиях, поэтому принципиальных ограничений для удаленного обновления нет.
На практике есть разница в основных сценариях использования, которые предполагаются авторами технологий прямо сейчас. В LoraWan минимальные скорости начинаются с сотен бит в секунду (хотя сама LoRa и приемопередатчики SemTech могут работать и на более низких скоростях), а UNB в качестве основных режимов, как было сказано в статье, используют скорости в десятки бит в канале. Это должно обеспечить лучший сбор показаний с удаленных датчиков, но на скоростях в 10 и более раз ниже удаленное обновление будет, очевидно, в 10 раз сложнее. Но в принципе, нет ограничений, почему бы не сделать ОФМ с любой скоростью передачи данных и примерно такими же характеристиками, как у LoRa в аналогичных режимах (Как пример — в описываемом стандарте описана поддержка скорости 25600 бит/с).
В частности, OFDM используется в Wi-Fi (есть даже открытая реализация, github.com/jhshi/openofdm) в LTE (совместно с SC-FDM) и, наверное, вообще почти везде.
Верификация проще, если доверять синтезу в САПРе, а также использовать стандартный интерфейс (я думаю, все поддерживают AXI), то можно верифицировать модуль на уровне матлаба или С. Что гораздо быстрее и не требует покупки Questasim/VCS. В матлабе, конечно, такая функциональность тоже дорогая (я думаю, все равно не дороже САПР от Cadence/Mentor), а вот в случае других HLS, верификация на С будет сравнительно быстрой и дешевой.
Говорят, что Simulink -> System Generator -> Intel/Xilinx позволяет делать что угодно, причем моделировать можно на уровне симулинка, что опять же попроще, чем в RTL. Разбираться с настройками придется и в САПР для верилога тоже.
Есть хорошие инструменты, которые должны работать с разными целевыми архитектурами — такие как маршрут Simulink-System Generator-Intel/Xilinx, а также платформо-независимые среды Mentor Catapult или Cadence Stratus, но их использование пока ограничивается еще и стоимостью.
Во－первых, раз сигнал гасится стенкой, значит в каждом магазине в большом ТЦ можно поставить по базовой станции, которые не будут друг другу мешать.
Во－вторых, массовое применение бимформинга со временем позволит использовать одни и те же частоты разным абонентам даже с одной станцией, при этом станция будет их разделять как раз за счет бимформинга.
Самое приятное, что неудобства временные (надеюсь) а улучшать связь потом можно будет годами за счет совершенствования модемов и антенн.
Судя по https://www.disk91.com/2015/news/technologies/one-day-at-sigfox/ у сигфокса полоса в обратном канале 600Гц, при такой полосе стандартные приемопередатчики обеспечивают чувствительность около -130дБм, что, конечно, не -140-150, которые узкополосные сети обещают в аплинке, но тоже вполне себе UNB. Никакого QAM.
Во-вторых, понятно, что приемник должен работать в том режиме, который позволяет его ТСХО. Странно было бы делать входной фильтр 100 гц при работе от кварца. Для дешевой системы входной фильтр нужно иметь в десятки килогерц.
В-третьих, не знаю, причем тут спектральная плотность, какая плотность у обсуждаемой bpsk можно легко нагуглить. Дальность связи можно оценить, посмотрев в документации, какая чувствительность у используемого «конкретного радиотрансивера» в используемом режиме. Я не спорю, что устройства, близкие к границе уверенного приема UL (который, к тому же, может работать на значительно более низких скоростях) такой DL не услышат, по-моему, это очевидно.
Заодно, кстати, можно отправлять такой DL в полосе, где ограничена плотность мощности.
Я же так и написал. В 3-4 раза шире. Вот, например, для сс1020/21 — citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.610.6775&rep=rep1&type=pdf
Frequency Separation доходит до 30% ширины входного фильтра.
Дальность при этом понятно какая будет, wide area будет не слишком wide, но мы здесь обсуждаем удаленное обновление и скорость 25600.
Понятно, что не зная диапазон частот устройство не сделать.
Видимо, предполагается, что диапазоны частот будут описаны где-то отдельно, типа частотного плана конкретной страны или конкретного вендора БС. (у ЛоРаВан же частоты для разных стран в отдельном документе описаны?)
По DL согласен, там даже скорость описана как «В зависимости от реализации конкретного радиотрансивера», то есть не имея доступа к этому самому трансиверу остается только догадываться, что прилетит от БС в ответ (может, QAM-256?).
С другой стороны, что в этом такого? У устройств разных производителей может быть одинаковый UL (в соответствии со стандартом) и разный DL, под конкретные БС и/или конкретные требования со стороны самого устройства, какие-то базовые станции (более дорогие?) будут поддерживать несколько разных режимов DL.
Наверное, производитель устройств в состоянии узнать у производителя БС, какой там радиотрансивер используется?
К тому же, это дает полную свободу тем, кто будет делать устройство + БС самостоятельно, нет проблем хоть SX-12xx поставить на обратный канал. ( примерно как Гудван, да?)
Я думаю, что для распространения технологии производства БС провайдерам UNB можно было бы предлагать приемники как IP для встраивания в имеющееся железо и популярные отладочные, макетные платы и всякие SDR на различном популярном железе.
Если не гнаться за лучшей достижимой чувствительностью, то простой приемник с полосой килогерц 20-25 можно сделать на чем угодно, упростив декодирование.
В конце концов, SemTech же предлагает чипы для создания станций. Понятно, что аналог SX1301 сделать будет слишком дорого, но выпускать IP с адекватной защитой от копирования вполне можно было бы.
То есть обратный канал станет шире и быстрее от плохих ТСХО, от кварца работать не будет. Справедливости ради, ЛоРа тоже на полосах уже 125кГц требует ТСХО, так что ничего неожиданного.
Со стороны БС-то вполне можно принять bpsk не хуже, чем ЛоРу.
А так да, возможность сделать БС на одном приемопередатчике это плюс ЛоРы.
Но, собственно, какая разница, ничем не хуже и не лучше ЛоРы.
Он обеспечивает чувствительность до -137, что позволяет сделать нормальный обратный канал, сравнимый со стандартной LoRa.
Если ориентироваться на -130, то выбор очень широк.
Сложность в том, что на стороне БС должен быть хороший алгоритм и протокол взаимодействия устройства и БС для оценки расхождения их генераторов. То есть опять это будет какая-то секретная часть. А само устройство-то может быть сколь угодно простым.
Сложность в алгоритмах и прошивке, которые, соответственно, закрыты и/или под патентами.
Собственно, LoRa тоже вся под патентами, а производитель приемопередатчиков вообще один. Я думаю, она настолько внешне открыта потому, что модуляция в ней нестандартная, и в обход Семтека сделать устройство на LoRa нереально: во-первых, модуляция под патентами, во-вторых, сделать нестандартный интегральный приемопередатчик еще (значительно) более сложно, чем базовую станцию UNB.
UNB же использует серийную элементную базу, поэтому авторы технологий сохраняют базовые станции за собой. Зато SigFox'у или Стрижу/Вавиоту можно отправить сообщение почти с любого серийного приемопередатчика.
На практике есть разница в основных сценариях использования, которые предполагаются авторами технологий прямо сейчас. В LoraWan минимальные скорости начинаются с сотен бит в секунду (хотя сама LoRa и приемопередатчики SemTech могут работать и на более низких скоростях), а UNB в качестве основных режимов, как было сказано в статье, используют скорости в десятки бит в канале. Это должно обеспечить лучший сбор показаний с удаленных датчиков, но на скоростях в 10 и более раз ниже удаленное обновление будет, очевидно, в 10 раз сложнее. Но в принципе, нет ограничений, почему бы не сделать ОФМ с любой скоростью передачи данных и примерно такими же характеристиками, как у LoRa в аналогичных режимах (Как пример — в описываемом стандарте описана поддержка скорости 25600 бит/с).