Комментарии 21
Интересно, спасибо. Сразу несколько вопросов, сначала простых:
1. Реально ли использовать в LoRa CDMA поверх семи spreading factor'ов? Или 7 — это предел абонентов, если не используется TDMA?
2. Почему битрейт на самом быстром SF решили ограничить 5 кбит/с, если Шеннон сотоварищи обещают нам много больше?
И чуть более философских:
3. Пусть у нас ширина канала 125 кГц, а на улице жаркий солнечный день. Кварц абонента уходит на 25 кГц, и когда он говорит на самом быстром SF, его сигнал начинает вылезать за границы канала с одного из краев. Наблюдается ли это на практике? И если да, то что делать — смириться с потерями, перейти на меньший SF, что-то еще?
4. Обратная связь БС → абонент. Насколько уменьшается емкость сети с ее появлением (на вашем опыте)? Здравый смысл подсказывает, что проблемы начинаются, когда ресурсы TDMA исчерпаны. Но при этом, казалось бы, никто не мешает зарезервировать 5 секунд в конце каждой минуты для получения коротких сообщений от БС в духе «абонент такой-то, прием подтверждаю» — это 10% всего эфира, не более.
1. Реально ли использовать в LoRa CDMA поверх семи spreading factor'ов? Или 7 — это предел абонентов, если не используется TDMA?
2. Почему битрейт на самом быстром SF решили ограничить 5 кбит/с, если Шеннон сотоварищи обещают нам много больше?
И чуть более философских:
3. Пусть у нас ширина канала 125 кГц, а на улице жаркий солнечный день. Кварц абонента уходит на 25 кГц, и когда он говорит на самом быстром SF, его сигнал начинает вылезать за границы канала с одного из краев. Наблюдается ли это на практике? И если да, то что делать — смириться с потерями, перейти на меньший SF, что-то еще?
4. Обратная связь БС → абонент. Насколько уменьшается емкость сети с ее появлением (на вашем опыте)? Здравый смысл подсказывает, что проблемы начинаются, когда ресурсы TDMA исчерпаны. Но при этом, казалось бы, никто не мешает зарезервировать 5 секунд в конце каждой минуты для получения коротких сообщений от БС в духе «абонент такой-то, прием подтверждаю» — это 10% всего эфира, не более.
1. Нет. Даташит описывает только семь валидных значений для соответствующего конфигурационного регистра чипа, как он будет реагировать на что-то иное в нём — одному Семтеку известно. Скорее всего, ошибкой.
2. Шеннон с коллегами устанавливает теоретический предел. Практический много чем определяется — той же работой демодуляторов, например.
3. При уходе частоты на 30 % от ширины полосы (т.е. в стандартном случае — на 37,5 кГц) будет 10 % ошибок в принятых пакетах. С потерями ничего не делать — изначально проектировать систему так, чтобы они были приемлемыми; для LoRa в этом нет принципиальных сложностей — на абонентское устройство ставится кварц с ±10±15 ppm, на БС — TCXO, там лишний доллар стоимости роли не играет.
4. Ёмкость сферической сети в вакууме в таких системах вообще не имеет смысл — я морщусь каждый раз, когда читаю что-то в духе «наша супер-пупер БС может обслуживать миллион абонентов». Ну да, может, если каждый из них передаёт два байта раз в неделю. А если пятнадцать байт и раз в час — то не может.
Поэтому надо считать на конкретном примере: сколько абонентов, с какой периодичностью выходят в эфир, сколько данных передают. А там уже можно думать и о прикручивании TDMA, причём описанная вами схема — это чрезмерное усложнение, если мы можем рассортировать абонентов и выделить каждому слот для передачи, достаточно работать по классу А, когда подтверждение отправляется сразу после приёма данных. А если у нас каша и ничего мы рассортировать не можем, то для начала абонент и не узнает, когда случатся эти 5 секунд (это, кстати, типичный класс B — абоненту назначают время, когда ему надо слушать эфир, но не надо в него ничего передавать; класс B удобен для рассылки броадкастов абонентам, сидящим на батарейном питании — можно всем поставить один и тот же короткий слот приёма, а всё остальное время они будут спать).
2. Шеннон с коллегами устанавливает теоретический предел. Практический много чем определяется — той же работой демодуляторов, например.
3. При уходе частоты на 30 % от ширины полосы (т.е. в стандартном случае — на 37,5 кГц) будет 10 % ошибок в принятых пакетах. С потерями ничего не делать — изначально проектировать систему так, чтобы они были приемлемыми; для LoRa в этом нет принципиальных сложностей — на абонентское устройство ставится кварц с ±10±15 ppm, на БС — TCXO, там лишний доллар стоимости роли не играет.
4. Ёмкость сферической сети в вакууме в таких системах вообще не имеет смысл — я морщусь каждый раз, когда читаю что-то в духе «наша супер-пупер БС может обслуживать миллион абонентов». Ну да, может, если каждый из них передаёт два байта раз в неделю. А если пятнадцать байт и раз в час — то не может.
Поэтому надо считать на конкретном примере: сколько абонентов, с какой периодичностью выходят в эфир, сколько данных передают. А там уже можно думать и о прикручивании TDMA, причём описанная вами схема — это чрезмерное усложнение, если мы можем рассортировать абонентов и выделить каждому слот для передачи, достаточно работать по классу А, когда подтверждение отправляется сразу после приёма данных. А если у нас каша и ничего мы рассортировать не можем, то для начала абонент и не узнает, когда случатся эти 5 секунд (это, кстати, типичный класс B — абоненту назначают время, когда ему надо слушать эфир, но не надо в него ничего передавать; класс B удобен для рассылки броадкастов абонентам, сидящим на батарейном питании — можно всем поставить один и тот же короткий слот приёма, а всё остальное время они будут спать).
Вопрос на самом деле про включение в сеть новых абонентов, когда ресурсы TDMA уже исчерпаны.
Способ с 5 секундами вроде бы неплох: при включении абонент передает в сеть "я новенький" и ждет минуту, в течение которой получает подтверждение, расписание, явки, пароли и так далее. А после этого работает по расписанию. Не получилось — ждет рандомное время, пробует еще раз.
В принципе, с тем же успехом можно зарезервировать один из SF для передатчика БС. Наверное, еще какие-нибудь приемы есть, было бы интересно узнать.
Так а в чём практический смысл этих 5 секунд? Новенький стучится в сеть, получает временной слот для передачи (например, +400 секунд), ждёт его, передаёт свои данные, тут же получает ACK, в котором указан следующий временной слот для передачи. Все счастливы. Если у нас сеть с известными абонентами, а не публичный LoRaWAN — хорошая гибкая схема.
Отдельный SF для передатчика резервировать бессмысленно — если передатчик работает, всё остальное умерло. Тупо потому, что даже если его вывести на отдельный чип и отдельную антенну, она всё равно на БС будет стоять в 20 см от приёмных антенн — и забьёт на них любые прочие сигналы. Кроме того, фиксированный SF — это с многоканальной БС неэффективно: выбрать низкую скорость — потерять эффективность работы с близкими абонентами, выбрать высокую — не достучаться до дальних.
Отдельный SF для передатчика резервировать бессмысленно — если передатчик работает, всё остальное умерло. Тупо потому, что даже если его вывести на отдельный чип и отдельную антенну, она всё равно на БС будет стоять в 20 см от приёмных антенн — и забьёт на них любые прочие сигналы. Кроме того, фиксированный SF — это с многоканальной БС неэффективно: выбрать низкую скорость — потерять эффективность работы с близкими абонентами, выбрать высокую — не достучаться до дальних.
Смысл с одной стороны в том, чтобы иметь строгое расписание — так сказать, ordnung =).
А если серьезно, то в нагруженной системе БС во время ответа новенькому наверняка пропустит сообщения от других абонентов. Им придется повторять посылку, что может привести к наложению на других абонентов, и так далее — в итоге есть опасение, что нагрузка на эфир только возрастет.
Про передатчик БС понятно — когда говорят пушки, музы молчат.
Так в системе с тотальным орднунгом БС знает, когда другие абоненты хотя послать сообщение — так что новенькому ответить в ближайший свободный слот (новенький при джойне в сеть, очевидно, должен ждать первого ответа какое-то разумное время).
Так по сути оба решения ("5 секунд" и "когда получится") — одного поля ягоды: новенький ждет какое-то время ответа и потом добавляется в расписание. Разница в количестве орднунга.
Да, по поводу расписания. Пусть один из абонентов послал данные на БС, но не получил подтверждения и нового времени ожидания. Тогда он попробует передать данные еще раз. Понятно, что при полном орднунге вторая попытка наступит ровно через один период орднунга.
А вот если орднунга нет, то какое время ожидания будет оптимальным? То, которое было в прошлый раз — так это долго, плюс не факт, что не будет коллизии. Рандомное небольшое число секунд — это быстро, но вероятность коллизии становится еше выше.
Второе — рандомное небольшое число секунд. В нагрузку сети всё равно должен закладываться некоторый запас на помехи и последующие коллизии, при любом орднунге.
А зачем в SX1301 49 демодуляторов, если кодов ортогональных только 7?
Там навороченная система из этих демодуляторов внутри:
* 1 канал FSK
* 1 канал LoRa, работающий с полосой 125, 250 или 500 кГц с одним конкретным выбранным SF
* 8 каналов LoRa, работающих только с полосой 125 кГц, зато с любым SF (без его предварительного указания) и с произвольным сдвигом частоты для каждого канала на ±2 МГц от центральной
Собственно, вот эти 8 каналов Semtech рассматривает как «эмуляцию 48 каналов LoRa».
Сейчас дополню в статье, чтобы было понятнее.
* 1 канал FSK
* 1 канал LoRa, работающий с полосой 125, 250 или 500 кГц с одним конкретным выбранным SF
* 8 каналов LoRa, работающих только с полосой 125 кГц, зато с любым SF (без его предварительного указания) и с произвольным сдвигом частоты для каждого канала на ±2 МГц от центральной
Собственно, вот эти 8 каналов Semtech рассматривает как «эмуляцию 48 каналов LoRa».
Сейчас дополню в статье, чтобы было понятнее.
Из статьи:
Ниже:
Ну вы и загнули — обработка гигагераца в реальном времени! Обработка ведётся не на гигагерце, а, всего лишь, на сотнях кГц. Не слишком широкая полоса спектра под телеметрию целиком переносится, можно сказать, на низкие частоты — квадратурные составляющие с дискретизацией порядка 200кГц. Не бог весть какая скорость. Хотя да, для реализации приёма, близкого к оптимальному, вычислений много — Стриж пишет, что NVIDIA CUDA применяет в «больших» БС. Вы пишите так, будто бы с точки зрения обработки LoRa нужно меньше ресурсов. Если обработка и там, и там оптимальна, то необходимая производительность определяется лишь количеством информации, которое необходимо получить. Для полноценной LoRaWAN полоса обрабатываемого эфира ещё шире, поэтому «рилтаймовость» даже больше. Просто до поры до времени она от вас спрятана в относительно скромном чипе.
olartamonov, а здесь вы пишите:
И ниже в комментариях:
Выходит, проблема со стабильностью частоты стоит и перед LoRaWAN. Как я вижу по водопаду спектра передатчиков UNB Стрижа, они наплевали на нестабильность частот передатчиков в аплинке, передавая сообщение с одного модема последовательно на двух разных частотах. Не замерял, возможно, со случайным сдвигом между передачами. Так что побоку повышенная точность кварцев — можно использовать дешёвые. Доллар в пользу UNB.
Если на стороне БС для UNB удастся реализовать оптимальное декодирование DBPSK с избыточностью, то не исключаю возможности успешного декодирования сообщений даже при их взаимном наложении в эфире. Если взаимные помехи модемов не мультипликативны и сообщения не когерентны, то сигнал-шум упадёт, но возможнось расшифровки не пропадет полностью. В общем, чем ближе методы приёма к оптимальным, тем размытее граница между широкополосными и узкополосными модуляциями. Остаются лишь соотношения энергий сигнала и шума за время и в полосе сообщения. И мне нравится фундаментальное преимущество узкой полосы — низкая энергия посторонних шумов эфира и приёмного тракта в полосе сигнала.
В защиту LoRaWAN скажу, что сеть будет внедряться и работать повсеместно. Протоколы взаимодействия хорошие, гибкие. Все проблемы решаются спросом. Будет спрос — буду БС стоять хоть в каждом квартале, каждом дворе — пикосоты. Проблемы ёмкости отпадают с увеличением количества малых БС.
…оцифровка и последующий спектральный анализ широкого диапазона радиоэфира (десятки-сотни килогерц) в реальном времени… Такая система действительно позволяет принимать большое число абонентских устройств одновременно, но это — цифровая обработка сигнала на близкой к гигагерцу частоте в реальном времени, то есть, тяжелая вычислительная задача, требующая от БС весьма серьёзных ресурсов.
Ниже:
Как мы увидели выше, для эффективной работы БС должна делать спектральный анализ принимаемого широкополосного сигнала в реальном времени, выделяя из него узкополосные сигналы отдельных абонентов. Слова «в реальном времени» имеют здесь вполне конкретный количественный смысл: частота вычисления БПФ — это частота дискретизации сигналов абонентов. Поэтому любая попытка серьёзно увеличить скорость связи с абонентами в UNB-системе требует столь же серьёзного увеличения производительности системы цифровой обработки сигнала. А при том, что мы говорим о ЦОС с исходной частотой почти в гигагерц — приятного в таком требовании мало..
Ну вы и загнули — обработка гигагераца в реальном времени! Обработка ведётся не на гигагерце, а, всего лишь, на сотнях кГц. Не слишком широкая полоса спектра под телеметрию целиком переносится, можно сказать, на низкие частоты — квадратурные составляющие с дискретизацией порядка 200кГц. Не бог весть какая скорость. Хотя да, для реализации приёма, близкого к оптимальному, вычислений много — Стриж пишет, что NVIDIA CUDA применяет в «больших» БС. Вы пишите так, будто бы с точки зрения обработки LoRa нужно меньше ресурсов. Если обработка и там, и там оптимальна, то необходимая производительность определяется лишь количеством информации, которое необходимо получить. Для полноценной LoRaWAN полоса обрабатываемого эфира ещё шире, поэтому «рилтаймовость» даже больше. Просто до поры до времени она от вас спрятана в относительно скромном чипе.
olartamonov, а здесь вы пишите:
Одна из серьёзных технических проблем UNB-систем — нестабильность частоты кварцевых резонаторов, задающих рабочую частоту абонентского устройства. Типовой хороший кварц имеет суммарную погрешность ±25 ppm, то есть при частоте несущей 869 МГц реальное отклонение от неё может достигать 21,725 кГц.
И ниже в комментариях:
3. При уходе частоты на 30 % от ширины полосы (т.е. в стандартном случае — на 37,5 кГц) будет 10 % ошибок в принятых пакетах. С потерями ничего не делать — изначально проектировать систему так, чтобы они были приемлемыми; для LoRa в этом нет принципиальных сложностей — на абонентское устройство ставится кварц с ±10±15 ppm, на БС — TCXO, там лишний доллар стоимости роли не играет.
Выходит, проблема со стабильностью частоты стоит и перед LoRaWAN. Как я вижу по водопаду спектра передатчиков UNB Стрижа, они наплевали на нестабильность частот передатчиков в аплинке, передавая сообщение с одного модема последовательно на двух разных частотах. Не замерял, возможно, со случайным сдвигом между передачами. Так что побоку повышенная точность кварцев — можно использовать дешёвые. Доллар в пользу UNB.
Если на стороне БС для UNB удастся реализовать оптимальное декодирование DBPSK с избыточностью, то не исключаю возможности успешного декодирования сообщений даже при их взаимном наложении в эфире. Если взаимные помехи модемов не мультипликативны и сообщения не когерентны, то сигнал-шум упадёт, но возможнось расшифровки не пропадет полностью. В общем, чем ближе методы приёма к оптимальным, тем размытее граница между широкополосными и узкополосными модуляциями. Остаются лишь соотношения энергий сигнала и шума за время и в полосе сообщения. И мне нравится фундаментальное преимущество узкой полосы — низкая энергия посторонних шумов эфира и приёмного тракта в полосе сигнала.
В защиту LoRaWAN скажу, что сеть будет внедряться и работать повсеместно. Протоколы взаимодействия хорошие, гибкие. Все проблемы решаются спросом. Будет спрос — буду БС стоять хоть в каждом квартале, каждом дворе — пикосоты. Проблемы ёмкости отпадают с увеличением количества малых БС.
Ну вы и загнули — обработка гигагераца в реальном времени! Обработка ведётся не на гигагерце, а, всего лишь, на сотнях кГц. Не слишком широкая полоса спектра под телеметрию целиком переносится, можно сказать, на низкие частоты — квадратурные составляющие с дискретизацией порядка 200кГц. Не бог весть какая скорость
В антенну прилетел почти гигагерц — соответственно, этот почти гигагерц таки надо как минимум оцифровать. С хорошим частотным и временным разрешением.
Вы пишите так, будто бы с точки зрения обработки LoRa нужно меньше ресурсов. Если обработка и там, и там оптимальна, то необходимая производительность определяется лишь количеством информации, которое необходимо получить
Не порите чушь, ей больно. В LoRa задача найти в 500 кГц эфира, где именно тут только что квакнул передатчик с полосой 100 Гц, вообще не стоит.
Выходит, проблема со стабильностью частоты стоит и перед LoRaWAN
Вообще-то ±10±15 ppm — это максимально возможный уход частоты на 21,7 кГц. Что, как нетрудно заметить, значительно меньше вышеупомянутых 37,5 кГц, при которых LoRa ещё работает.
Как я вижу по водопаду спектра передатчиков UNB Стрижа, они наплевали на нестабильность частот передатчиков в аплинке, передавая сообщение с одного модема последовательно на двух разных частотах
Смешались в кучу кони, люди. Почему они наплевали на стабильность — написано в тексте: потому что у них нет технически разумных способов эту стабильность обеспечить. Почему они передают последовательно на двух частотах — полагаю, это оригинальный способ борьбы с коллизиями и помехами, «хоть один дойдёт».
В антенну прилетел почти гигагерц — соответственно, этот почти гигагерц таки надо как минимум оцифровать. С хорошим частотным и временным разрешением.
Не нужно оцифровывать гигагерц. Используем прямой перенос спектра (естественно, с хорошим временным разрешением) и АЦП с частотой дискретизации чуть выше, чем желаемая полоса эфира. То есть, после переноса спектра, который не слишком сложен, используются обычные, чуть ли не аудио АЦП. Не нужен «рилтайм» на ГГц. Достаточно квадратурного смесителя с контролируемым джиттером.
На выходе квадратурные составляющие, из которых восстанавливается целый спектр шириной плюс-минус частота дискретизации от 1/4 частоты опорного генератора. Для субгигагерца немногим сложнее, чем на рисунке. Или в LoRa не так делается? Они гигагерц напрямую оцифровывают? Вряд ли.
Не порите чушь, ей больно. В LoRa задача найти в 500 кГц эфира, где именно тут только что квакнул передатчик с полосой 100 Гц, вообще не стоит.
Угу. Задача декодирования широкополосного сигнала много проще, по-вашему. ПМСМ, обработку успешно упаковали в чип, поэтому она вам кажется такой простой.
Про стабильность частоты: не можешь побороть? Возглавь! Весма действенный принцип. Нет смысла достигать стабильности высокой ценой (стоимость и потребление TXCO) в то время как вероятность коллизй с потерей данных невысока даже при активности сотни нескоординированных модемов в полосе ~200кГц.
Да, можете отметить в табличке. Из открытых материалов Стрижа, используемая модуляция — DBPSK. Относительная двоичная фазовая манипуляция.
Они гигагерц напрямую оцифровывают? Вряд ли.
Почитайте что-нибудь на досуге. Потом ответьте сами себе на вопрос, надо ли вообще оцифровывать несущую или куда-либо её переносить в LoRa.
Угу. Задача декодирования широкополосного сигнала много проще, по-вашему. ПМСМ, обработку успешно упаковали в чип, поэтому она вам кажется такой простой.
Мне она кажется простой, потому что я немного знаю схему модуляции LoRa, а также держу в руках крошечный копеечный чип, способный эту модуляцию демодулировать. А не Jetson TK1 с NVIDIA CUDA, которому вентилятор нужен, чтобы он от натуги не сдох (кстати, интересно, как оно будет работать в необслуживаемом варианте зимой на крыше дома, кхм).
Вообще удивительно, как вы игнорируете физический уровень, который у LoRa и Стрижа тупо разный.
Про стабильность частоты: не можешь побороть? Возглавь! Весма действенный принцип. Нет смысла достигать стабильности высокой ценой (стоимость и потребление TXCO) в то время как вероятность коллизй с потерей данных невысока даже при активности сотни нескоординированных модемов в полосе ~200кГц.
Ну то есть CUDA и отсутствие полноценной обратной связи вы считаете низкой ценой?
Почитайте что-нибудь на досуге. Потом ответьте сами себе на вопрос, надо ли вообще оцифровывать несущую или куда-либо её переносить в LoRa.
Почитал. В статье "Возможности использования радиотрансиверов компании Semtech" картинка (с моими пометками):
Стандартная схема. Во всех ВЧ радиоинтерфейсах стараются сразу перенести полосу сигнала на нижние частоты при помощи простых квадратурных смесителей. В на картинке после смесителя АЦП с передискретизацией, поэтому частота работы модуляторов дельта-сигма АЦП больше итоговой частоты дискретизации полосы сигнала. Дальше дециматор/ФНЧ. На демодулятор отсчёты квадратурных составляющих сигнала поступают уже с частотой дискретизации лишь чуть больше полосы принимаемого сигнала. И это даже не десятки МГц, а в лучшем случае единицы МГц.
То же самое и у UNB Стрижа. АЦП и ЦОС работают с частотами дискретизации порядка 200кГц-500кГц, не более. Поэтому меня покоробило ваше утверждение, что нужно производить обработку сигнала на гигагерце в реальном времени. Оно, по моему, не соответствует действительности.
Вообще удивительно, как вы игнорируете физический уровень, который у LoRa и Стрижа тупо разный.
Разный он только с точки зрения модуляции и протокола. На уровне радиочастотной части (до АЦП включительно) принципиальных отличий нет. Так же при оптимальном приёме — с точки зрения радиочастотного ресурса и соотношения энергий все способы передачи равноценны. Вопрос лишь в том, насколько оптимальный приём удаётся организовать.
Мне она кажется простой, потому что я немного знаю схему модуляции LoRa, а также держу в руках крошечный копеечный чип, способный эту модуляцию демодулировать. А не Jetson TK1 с NVIDIA CUDA, которому вентилятор нужен, чтобы он от натуги не сдох (кстати, интересно, как оно будет работать в необслуживаемом варианте зимой на крыше дома, кхм).
И этот крошечный чип может одновременно декодировать сотни сигналов модемов?
Конечно, в нормальных условиях за счёт работы ближних LoRaWAN модемов на высоких скоростях, у вашего копеечного чипа хватит ресурсов на много пользователей. На большой скорости модемы быстрее «отстерляются» в эфир, чем UNB. Но количество одновременно декодируемых каналов меньше, чем у UNB BS с мощным DSP. На больших площадях покрытия с низкими SF уже вопрос, какая БС окажется эффективнее.
Насколько мне известно, уже доступны маленькие БС Стриж как наружного исполнения, так и для помещений. Наверняка они имеют меньшую производительность и ёмкость, чем большие БС на CUDA. И меньшую стоимость.
Ну то есть CUDA и отсутствие полноценной обратной связи вы считаете низкой ценой?
Вопрос в применении. Для БС операторского класса на большую площадь покрытия, с учётом того, что модемы UNB пока дешевле, узкополосная система может быть выгодна. Кроме того, вопрос обратного канала (на LoRaWAN или на 433МГц — я ещё не разобрался) у Стрижа решён — держал в руках и тестировал оборудование, на котором нисходящий канал работает. Для применения уровня ТСЖ — да, LoRaWAN интересное решение, может быть собрано «на коленках». С другой стороны, у Стрижа уже есть маленькие БС. Так что это уже вопрос предпочтений: ценит ли заказчик открытость решений и возможнотсь выбора поставщиков радиомодулей и сильно ли ему нужно создавать свою независимую сеть?
Разный он только с точки зрения модуляции и протокола. На уровне радиочастотной части (до АЦП включительно) принципиальных отличий нет
Ага. Примерно как гигабитный эзернет и RS232 — на уровне медной проволоки принципиальных отличий нет.
Только дальше у LoRa случается несложный демодулятор, легко реализуемый в дешёвом кремнии,, а у UNB — БПФ по всему каналу в реальном времени, требующий конской вычислительной мощности. Как тут недавно в комментариях выразились — на достаточно низкой скорости LoRa можно вручную декодировать с помощью линейки с миллиметровыми делениями.
Насколько мне известно, уже доступны маленькие БС Стриж как наружного исполнения, так и для помещений
Насколько мне известно, если большая БС имеет мозгов на сканирование 500 кГц полосы, а маленькая — только на 50 кГц, то сети под эти БС внезапно оказываются друг с другом несовместимы.
Интересно, не поэтому ли «Стриж» скромно умалчивает о технических деталях своих решений?
И этот крошечный чип может одновременно декодировать сотни сигналов модемов?
Он может декодировать как минимум один сигнал. Крошечный чип в UNB может декодировать ровно ноль сигналов.
Кроме того, вопрос обратного канала (на LoRaWAN или на 433МГц — я ещё не разобрался) у Стрижа решён — держал в руках и тестировал оборудование, на котором нисходящий канал работает
Какой LoRaWAN, какие 433 МГц у Стрижа? Вы вообще о чём? Вопрос обратного канала у них решён только в оборудовании класса А, потому что никак иначе его в UNB решить за разумные деньги технически невозможно.
Грубо говоря, на уровне медной проволоки, до демодулятора, подходы одинаковы.
Хочу убедиться, что вы понимаете, что никакой «цифровой обработки сигнала на близкой к гигагерцу частоте в реальном времени» в UNB-системах, равно как и в LoRa, не ведётся. Эта ваша формулировка недвусмысленно предполагает, что цифровая обработка сигнала ведётся на частоте выборки порядка 1ГГц. Это не соответствует действительности для практических реализаций ни UNB, ни LoRaWAN систем. И там, и там используются приёмники прямого преобразования и принцип нулевой промежуточной частоты, когда частота выборок сигнала, на которой ведётся цифровая обработка, лишь немного превышает ширину обрабатываемой полосы эфира. Поправьте, пожалуйста, в статье.
По полосе эфира малой БС попробую спросить у Стрижа. Если полоса уже, то под эту БС нужен отдельная серия («батч») модемов прошитых на конкретную частоту. Что не отменяет совместимости этих модемов с «большой» БС.
Касательно обратного канала Стрижа. При проверке БС я не увидел в полосе 868МГц передачи от БС, но обратный канал при этом срабатывал. Впрочем, я мог принять сигнал БС за часть ответа модема, который даётся после получения сообщения от БС. Ещё, антенна обратного канала отдельная. Из поставки Стрижа — диполь. И мне она показалась великоватой для 868МГц. Так что мне пока совсем непонятно, на какой частоте и с какой модуляцией реализован обратный канал.
Хочу убедиться, что вы понимаете, что никакой «цифровой обработки сигнала на близкой к гигагерцу частоте в реальном времени» в UNB-системах, равно как и в LoRa, не ведётся. Эта ваша формулировка недвусмысленно предполагает, что цифровая обработка сигнала ведётся на частоте выборки порядка 1ГГц. Это не соответствует действительности для практических реализаций ни UNB, ни LoRaWAN систем. И там, и там используются приёмники прямого преобразования и принцип нулевой промежуточной частоты, когда частота выборок сигнала, на которой ведётся цифровая обработка, лишь немного превышает ширину обрабатываемой полосы эфира. Поправьте, пожалуйста, в статье.
По полосе эфира малой БС попробую спросить у Стрижа. Если полоса уже, то под эту БС нужен отдельная серия («батч») модемов прошитых на конкретную частоту. Что не отменяет совместимости этих модемов с «большой» БС.
Касательно обратного канала Стрижа. При проверке БС я не увидел в полосе 868МГц передачи от БС, но обратный канал при этом срабатывал. Впрочем, я мог принять сигнал БС за часть ответа модема, который даётся после получения сообщения от БС. Ещё, антенна обратного канала отдельная. Из поставки Стрижа — диполь. И мне она показалась великоватой для 868МГц. Так что мне пока совсем непонятно, на какой частоте и с какой модуляцией реализован обратный канал.
У Стрижа было решение с обратной связью на 446 МГц с конской мощностью в полватта. Объяснять, почему это — костыли на велосипеде, я полагаю, не надо.
Что такое «поставка Стрижа» — вообще одному Стрижу ведомо. У них минимум три аппаратные платформы чисто по приёмопередатчикам (SiLabs, SX1276, Axsem), а уж что там по протоколам и антеннам…
Что такое «поставка Стрижа» — вообще одному Стрижу ведомо. У них минимум три аппаратные платформы чисто по приёмопередатчикам (SiLabs, SX1276, Axsem), а уж что там по протоколам и антеннам…
Какие дальности LoRa Link(ов) удалось достичь на разных битовых скоростях LoRa?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Связь в интернете вещей: LoRa против UNB. Часть 3: технические тонкости