repstosw

Это к вопросу о правильном ответе про максимальную скорость в LoRa. Не более. Запустил плату ATREB215-XPRO (на базе чипа AT86RF215) - собственных шумов на несколько порядков меньше, чем у модуля RF4463F30 и нет поражёнок (вход приёмника закорочен ВЧ-заглушкой): Проверил диапазоны 410 - 450 МГц и 863 - 903 МГц. Второй диапазон с подключенной антенной выдал менее замусоренный эфир: А теперь вопрос: если собственные шумы приёмника - в районе -127 дБм ... - 101 дБм (максимум), то зачем в даташите они тогда пишут, что чутьё в некоторых режимах -112 ... -107 дБм? Всёравно шумы платы и реализация сборки подрезает максимальный потенциал чипа приёмника...

Новый семтековский чип LLCC может в 2 раза больше в LoRa на Sub-GHz: https://www.semtech.com/products/wireless-rf/lora-connect/llcc68 И мощность на 2 дБ больше: Сделал замеры RSSI на всех каналах от 410 до 450 МГц. Без антенны, на короткозамкнутый вход или на 50 Ом - уровень ниже, но есть поражённые частоты. Частота 438 МГц выбрана неудачно, рядом с поражёнкой и ещё с эфира (когда с антенной) уровень шумов большой. 411-412 МГц лучше - на 5 дБ меньше шума.

Ну я смайл не просто так в сообщение поставил ))) У пейджера был приёмник с очень узкой полосой пропускания, которая делала приёмник сильно чувствительным + отсев много шума. Плюс диапазон метровый - частоты 160+ МГц. И работа только на приём. Принять с сопки передатчик и дурак сможет. А вот если передать от пейджера вверх на базу... (гипотетически) - не уверен, что связь будет такой же как и от передатчика к пейджеру. Ну и плюс как говорил ранее - делал передачу голоса на 800 бит в секунду с помощью LoRa, дальность там по прямой вышла около 8 км в городе. Тоже была с перебоями, если нарушается прямая видимость. Но восстанавливается на 100% как только прямая видимость. Ещё - увеличение мощности. Ватт 4-5 для начала. Даст увеличение дальности в 2 раза по сравнению с 1 Вт. Потом можно ещё кирпич на 16 Вт поставить, выигрыш в дальности будет в 4 раза )) Жуть полная. Как правило, это требует полностью переделывать весь транспорт пакета - распределение всего и вся. Сделал несколько пресетов: 5 - 10 - 12 - 15 FPS, видео 80x120 + Scale 2x, Video 160x240.

Можно. Обычно конденсатор на землю ставят там, где сопротивление выше. По идее даже 2 элемента достаточно: L1 и (C1 или C2). С3 - он нужен только, чтобы убрать постоянку, если к антенному гнезду планируется подключать какие-то измерители или короткозамкнутые по постоянке антенны (рамочные/петлевые антенны , J-антенна). Если нужно согласовать два усилителя, то там вообще может быть последовательный LC-контур. Так как сопротивления транзисторов сильно малы - и их проще включить в контур, нежели чем шунтировать ими контуры.

В какой именно? И при чём тут гадание? Ясно указаны характеристики. Неужели нельзя спрогнозировать или предположить причины такого поведения? А я думаю, что FEC работал в 4GFSK потому что он исправлял межсимвольную интерференцию, которой нет(или слабо выражена) у 2GFSK. Иначе как объяснить тот факт, что при 2GFSK модуляции пакет либо принимается без ошибок, либо вообще не принимается - приемник не видит даже преамбулу?

Такой эксперимент я уже проводил зимой. Здесь в теме где-то об этом писал, когда макеты проверял устройств. Один девайс был на балконе (7 этаж), антенна возле открытого окна. Со вторым девайсом бегал по городу. Дальность получилась 700+ метров. При этом важна была видимость антенн. Зашёл за дом - и связь пропала. Прошёл дом - снова виден балкон из которого торчит антенна - связь восстановилась. Суть моих последних испытаний в том, чтобы проверить устройства в наихудших условиях, когда два оператора находятся на земле. В этом случае дальность устойчивой связи 160 метров (1 Мбит/c), 200 метров (500 кбит/c) и 327 метров (125 кбит/c). И очень сильно зависит от прямой видимости антенн. Плюс загаженный эфир с шумами -82 дБм не дают приёмнику работать в полную чувствительность (-88 дБм ... - 97 дБм). Тут даже хвалёная ранее AT86RF215 не поможет - нужно искать другой диапазон частот с более низким уровнем помех. Или использовать подшумовой приём (когда приёмник может вытащить уровень сигнала меньше шума), как это сделано в LoRa. Но у LoRa скорость ограничена до 62 кбит/c (для Sub-GHz) и до 200 кбит/c - для 2.4GHz, который загажен шумами не меньше чем 430-440, ну и про бОльший PathLoss на 2.4 не забываем... И про то, что более высокие скорости даже в режимах LoRa не дадут большей дальности (мало чирпов). А хотелось, чтобы видео-девайсы были как пейджер, принимающий в любой точке города 🙃

Если пешком, а не на транспорте, то всегда находишься с левого или правого края магистрали на тротуаре для людей. Сколько бы я не смотрел участков авто-трасс, все они рано или поздно куда-то заворачивают. Плюс перепады по высоте- за бугром не видно ничего, транспорт уходит за линию горизонта. Дистанция видимости 200-300 м от силы.

Подразумевается, что это сделали китайцы. Теперь стоит задача - проверить что они сделали действительно близкое к 50 Ом.

Река и мост - дадут сразу выигрыш в 5 раз как минимум. Потому что высоты и водная поверхность. Нужен участок прямой дороги, которая земля или асфальт, без всяких высот и водных поверхностей.

Это даст гарантию того, что китайцы не на****и. И своя собственно настроенная по VNA антенна на 50 Ом - идеально состыкуется с передатчиком, с целью выдать бОльший процент мощности в антенну (в идеале 99%). Но такого не бывает. Интересен импеданс в "рабочей точке" - в заданном режиме, при заданной мощности и на заданной частоте и с заданной модуляцией в пределах заданной полосы.

Испытан новый конфиг: 2FSK, 125 кбит/c, девиация 31,25 кГц (индекс модуляции 0.5, MSK), полоса приёмника около 200 кГц. Дальность устойчивой связи 327 метров. Дальше трасса поворачивается, нет прямой видимости, связь с перебоями. И вообще, проблема за городом найти кусок прямой ровной трассы без перепадов и каких-либо строительных объектов по бокам (если стоять на дороге и никуда не подниматься). А при чём тут ECC? Зачем он упомянут? Если в контексте того, что на него тоже надо резервировать полосу - так это учтено уже: у меня на FEC отводится до 20% от всего пакета (в расчёт битрейта видео идёт только свободная от FEC часть буфера).

Предложения актуальны. По всем вопросам пишите на repstosw2018 @ gmail.com

Предложения актуальны. По всем вопросам пишите на repstosw2018 @ gmail.com

вообще никто не знает что-ли?

Зато не очень удобно для передачи данных. И увеличивает задержку на приёмной стороне. Это надо закодировать пачку фреймов, проверить, лезет ли она в буфер. Если не лезет, то перекодировать эту пачку повторно, снизив качество. Если кодировать по одному фрейму, то выходит большой шум визуально при смене кадров, из-за того что выделенный размер строго на один фрейм. А так получается - львиную долю жрёт ключевой кадр, а следующие за ним - намного меньше, что и даёт сжатие более эффективным, но более неудобным для потоковой передачи данных. Есть ещё режим кодирования по битрейту с использованием VBV буфера. Но сколько бы не ставил битрейт, кодер так и норовит вылезти за этот предел, приходится занижать битрейт на 20-30%, иначе результат кодирования не лезет в буфер. Смысл тогда указывать битрейт - не понятен. И вообще, почему нельзя было сделать режим кодирования, при котором серия фреймов гарантированно влезала в конкретный буфер. Вот в аудио-кодеке CELT есть такой режим - исходя из параметров разрядности, семплирования, длины фрейма и коэфф. сжатия - можно расчитать размер выходного фрейма, который константа. Формализую задачу: Необходимо передавать и принимать (full-duplex) два видео с размером кадра 160x240 10 FPS на расстояние 1 км, используя Omni-антенны на высоте не более 1,5 м от земли, по прямой.

И всё-же максимум сжатия с этим H264 выходит, исключительно, когда используются не только ключевые кадры. Для GOP=10 (каждый 10-й ключевой кадр, остальные производные от него) - выходит 9 кадров практически занимают мало места. Для 53 кбит/с видео 160x240 это будет выглядеть таким образом: Десятка смежных фреймов не превышает 6617 байт. Фул-дуплекс ещё, поэтому в обе стороны скорость : 53*2 = 106 кбит/c. Остальное - на звук + FEC + CRC. Впихивается в 125 кбит/c. Теоретический выигрыш в дальности: SQRT(824.5kHz/197.87kHz) = 2.04x Тоесть: 203 м * 2,04 = 414 метров. Пример видео 160x240 удовлетворяющее этим условиям (сгенерированное модифицированной версией minih264e_test.c с контролем размера фреймов: out.264 С учётом того, что в 90% случаев будет исключительно "говорящая голова", то конфигурация имеет право на существование.

Да везде помойка ))) Просмотрел полосу частот от 50 МГц до 3000 МГц. Много больших помоек в диапазоне 140-160 МГц, 420 - 510 МГц, потом есть на 840 - 880 МГц, потом GSM 900, GSM1800, WiFi 2.4 GHz - куча стволов торчит. Выбрать что-то менее шумное - мало представляется возможным. Разве что на 8xx МГц кое-где есть на 10 дБ меньше шума. Как раз одна из полос частот, отведённая для детских радиопереговорных устройств в РФ ))) Соваться в неизведанные частоты не хочется, чтобы не получить по шапке. ))) Остаётся либо повышать мощность или более эффективнее - использовать направленные антенны.

К вопросу дальности связи. Эфир - помойка. Потенциал приёмника не раскрыт: -97 дБм < -82.6 дБм. Для нормального приема нужен сигнал превышающий шумы как минимум на 10 дБ: -73 дБм.

Интересное поделие ))) А где вы его и сайт нашли? https://www.reg.ru/whois/?dname=pb-embedded.ru Дата регистрации домена: 2024-04-13 И уже столько отладочных плат )))

4GFSK 2GFSK Вот тут в статье написано, что переход к 4GFSK хоть и сужает полосу в 2 раза (выигрыш в чутье +3дБ), но переход к 4-позиционной модуляции - на 5 дБ гробится из-за разделения символов. При условии, если индекс модуляции(по внешней девиации частоты) тот же - 1. https://siliconlabs.my.site.com/community/s/article/4gfsk-vs-2gfsk-sensitivity-on-si446x?language=en_US В итоге возврат к 2GFSK - это выигрыш на : 5-3 = 2 дБ. А теперь считаем: 160 * SQRT( 10^(2/10) ) = 1.259x 160 = 201 метр. Что практически совпало с измеренной на практике дальностью. Итого, отказ от 4GFSK дал выигрыш в чутье +2 дБ или по дальности увеличение на +26%. AT86RF215 уделывают эти Si4463, за счёт более лучшей чувствительности: на 500 kbps заявлено чутьё -108 дБм для OQPSK модуляции! Si4463 даёт только -97 дБм для 2GFSK 500 kbps df=+/-250 kHz, тоесть на 11 дБ хуже! Из-за более качественного детектора в том числе. Теоретически выигрыш в дальности от применения AT86RF215 будет: SQRT( 10^(11/10) ) = 3.54x

Я говорил про картинку своего разрешения: 160x240 T113-s3 - это cortex-a7. По всей строгости нужно исправить параметры сборки. Чтобы не было сюрпризов. Выше я говорил, что до 1200 FPS это с картинкой 160x240. С картинкой 80x120 вообще - до 3300 FPS Это на ПК 3ГГц под виндой с включенным SSE2: gcc -Ofast -msse2 -DNDEBUG -fomit-frame-pointer -ftree-vectorize -fno-math-errno -fmax-errors=1 -c minih264e_test.c gcc -o minih264e_test.exe minih264e_test.o Как будет на T113, пока не пробовал. Пока занимаюсь радиотрактом. Плюс, как я говорил ранее -нужны будут несколько итераций кодировки - с проверкой на влезаемость в буфер фиксиованного размера - для передачи данных. У меня адаптивный алгоритм качества кодирования: вначале качество повышается - растёт с каждым кадром - от минимума к максимуму через определенный шаг. Если сжатый результат не влезает - качество минус шаг и перекодировка, если влезло - следующий кадр - качество растёт на плюс шаг. В итоге качество постоянно меняется исходя из картинки и критерия влезаемости в буфер. И да, H264 нужно использовать в режиме - когда каждый кадр ключевой (GOP=1). Потому что при разрушении одного кадра - не должны страдать следующие за ним. Сжатия в этом случе меньше, но всё равно больше чем у JPEG как минимум в 2 раза (субъективно визуально при том же качестве картинки).

В билд-скриптах указан Cortex-A8. Надеюсь под A7 скомпиляется. Если нет - попробую переделать. Если нужно чтобы всё было в Си, то не указывать постройку с Неоном.

Нет. LoRa сильно дохлая по скорости для передачи/приёма видео на приемлемом FPS.

Почему на 4GFSK 500 ksps inner.mod =83 kHz, BW = 820 kHz, f0=438 MHz - index mod. 0,333 - коды Рида-Соломона работают - пакет исправляется, и есть длинная зона(дистанция связи) когда, пакет можно успешно исправить. А на 2GFSK 500 kbps dev. 250 kHz, BW=820 kHzm f0=438 MHz - index mod. 1 - коды Рида-Соломона не работают - пакет тупо либо приходит целым (ничего не надо исправлять), либо пакет тупо не приходит - приёмник молчит (до исправления ошибок не доходит) - длинной зоны приёма пакетов с ошибками нет. Пакет приходит целый, либо вообще не приходит. Пакет стандартный: преамбула (64 байта), синхрослово(4 байта), данные (3 кБайта), CRC64(программный). Порог обнаружения преамбулы - 32 бита. Таймаут преамбулы - 30 байт. Почему? С чем это связано?

Провели ещё одно тестирование. Дальность устойчивой связи 203 метра. Дальше связь с перебоями. Параметры: Full-Duplex, мощность передатчика 1 Вт, модуляция 2GFSK, скорость 500 кбит/c, девиация +/-250 кГц, полоса 820 кГц, частота 438 МГц, антенны над землёй 1,5 метра, J-антенна настроенная в резонанс. Буфер данных 3000 байт. Пришлось уменьшить картинку в 2 раза по осям (была 160x240, стала 80x120), затем растянул аппаратным скейлером. Иначе JPEG безбожно пережимает в квадраты (качество на уровне 10-25%). Отказываюсь от JPEG, перехожу на H264. Кодировать буду софтово. Нашёл либу на сях для кодирования H264 - там и SSE2- и NEON- оптимизации есть. Собрал пока на ПК, SSE2 даёт выигрыш в 2,5 раза по скорости. H264 более эффективнее жмёт, чем JPEG, JPEG2000 и HTJ2K. Там исходная картинка 160x240 помещается в 3000 байт при качестве QP=29..30. Что уделывает JPEG в качестве и сжатии. https://github.com/lieff/minih264 На ПК с 3 ГГц в один поток с помощью SSE2 картинка 160x240 жмется с 900 - 1200 FPS. Надеюсь на T113-s3 скорость будет не хуже 10 FPS 😂. Ну ещё и несколько попыток сжатий надо делать, с проверкой на влезаемость в буфер. Хочу одно ядро на кодер отдать.