repstosw

Река и мост - дадут сразу выигрыш в 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 😂. Ну ещё и несколько попыток сжатий надо делать, с проверкой на влезаемость в буфер. Хочу одно ядро на кодер отдать.

Я не могу раскрывать все детали коммерческой версии проекта, потому что NDA. Там и печатная плата другая, и корпус есть с нормальным расположением кнопок/сенсорный дисплей, есть GUI и функционала в разы больше. То, что представлено в видео - это базовый функционал устройства со "спартанским"(минимальным) интерфейсом + часть моих изменений, как мне удобно. Что касается "сам хотел писать" - да: с кодом работают несколько человек.

Вот как раз декодировать программно проще, чем кодировать. Обосновывал отсутствием G2D у V3s и всего одним ядром, против трёх у T113-s3. Для своих целей посматриваю на R818. Там как раз G2D, H264, DVP, LCD, несколько ядер A53. Но вот насколько он в тренде? P.S. Кстати, у фулл-дуплекса есть ещё одно жесткое требование, ограничивающее дальность связи - приемник синхронизируется от удалённого передатчика: тоесть принял пакет, и тут же послал ответный пакет. У второго оператора также. Поэтому, достаточно кому-то одному находиться в тяжёлых условиях - связи не будет у двоих (в таком случае девайсы переходят в режим периодической отправки пакетов с псевдо-рэндомным интервалом, по истечению таймаута, чтобы связь восстановилась, когда условия приёма улучшатся).

Я тоже думал. Однако реалии оказались другими. Попробую провести ещё одни испытания - один абонент на балконе, второй на улице. Посмотрим, что будет. У голосовой рации полоса 25 кГц. А здесь полоса 850 кГц. У голосовой рации аналоговая передача данных - допустимы помехи, незначительно влияющие на распознаваемость речи. А здесь - передача цифрового сигнала, допускающего до 10% ошибок в пакете. У голосовой рации граничиный С/Ш = 3 дБ (УЧМ). А здесь С/Ш > 10дБ (а то и выше из-за 4GFSK). Если брать тупо только первый аргумент, то уменьшение дальности при расширении полосы: SQRT(850/25) ~ в 6 раз Я тоже делал передачу сжатого голоса (кодек MELP до 800 бит/c) с помощью трансивера LoRa. дальность на 1,2 Вт была - 8 км в городе по прямой. А тут 1 мегабит - вместо 1 кбита. Можно ещё попробовать отказаться от дуплекса (это было одно из требований заказчика, которому нужна была небольшая дальность) и перейти на полу-дуплекс (с кнопкой PTT как в рациях). Скорость тогда нужна будет в 2 раза меньше. Полоса будет уже в 2 раза - дальность выше в квадратный корень с 2 раз. На практике больше - так как приёмнику легче. Потом ещё ухудшить качество JPEG, добившись сжатия в 2 раза больше - ещё корень с 2. Может снизить FPS в раза 1,5-2. Или разрешение. Итого в 3 раза ещё можно увеличить дальность. Но это уже будет не дуплекс и качество картинки хуже. Или отказаться от T113-s3, и сделать на V3s (как я это хотел вначале с более эффективным кодеком H264 ). Но заказчику нужно было на t113-s3. Что он хотел - то я и сделал. Дальше чисто для себя конфигурирую... Кстати, если промоделировать дальность в каком-нибудь калькуляторе... Вот данные: Частота 438 МГц Высота антенн над землёй 1,5 м Мощность передатчика 1 Вт Чутьё приёмника -88 дБм (заявлена в даташите. Реально - хуже, из-за коммутации антенны на приём-передачу) Полоса пропускания приемника 850 кГц Битрейт 1 МБит/с (500 к симв./с) Модуляция 4GFSK BT=0.5 Максимально допустимый процент ошибочных байт в пакете: 10% Усиление антенны - как у J-антенны (+0,25 дБд) Импеданс: 50 Ом Прямая видимость

Испытали на дальность. Два человека, по девайсу в руке: антенны на расстоянии 1,5 метра от асфальта. Прямая видимость. Дистанция устойчивой связи 160 метров. Дальше - связь либо с перебоями, либо её нет вообще. Это с настроенными J-антеннами. С китайскими четверть-волновыми коротышами (которые на 433 МГц) - дальность устойчивой связи ещё меньше - 50 метров. В режиме full-duplex (50% приём, 50% передача) ток от литий ионки - 0.95 A. Ночная подсветка подкинет ещё +0.45 A тока (при 100% яркости. Яркость регулируется ШИМ). Речь шла об отладочных плататах MangoPi.

Ацетон не оставляет разводов, в отличие от метилового(технического) спирта. Кстати, заметил, что в последнее время маркировка на комплектующих тускнеет до безобразия после протирки спиртом. Раньше такого не было. Теперь, чтобы прочитать маркировку на компонентах - нужно светить фонариком. Китайцы стали маркировать тёмной краской свои детали. 1.25 Мбит/с (625 ксимв./с) . Из них 20% на коррекцию ошибок. Разрешение 160x240. 12 FPS (делал опции 5 - 10 - 12 - 15 FPS). Модуль на базе Si4463 (модуляция 4GFSK). У T113-s3 только MJPEG, поэтому сжатия меньше, чем у H264 (который у V3s). Свёл все характеристики в спойлер: Жду ясной погоды без дождя. Обнаружил, что разгон модуля Si4463 на +25% сильно ухудшает BER на 1.25 МБит/c: 40 ... 60 ошибок в пакете при минимальной мощности передатчика и аттенюаторах -60 дБ. Разгон был сделан путём перепайки штатного кварца в обвязке Si4463 - с 30 МГц - до 36 (+20%) и 37.5 МГц (+25%). Это давало до 1,25 Мбит/с вместо 1. Вернул обратно штатный кварц на 30 МГц и довольствуюсь скоростью 1 МБит/c: BER улучшился : 0 ... 2 ошибки в пакете (на аттенюаторах -60 дБ + слабая мощность передатчика). Модуль со снятой крышкой: К сожалению, это так. У меня на платах MangoPi поотлетали все пятачки test-point'ов. Это которые TV_IN, TV_OUT, HP_OUT и другие... Просто не выдержали многократной пайки. Платы, которые сделали на заказ в Новосибирске, напротив - обладают большим запасом прочности: пятаки и дорожки не отслаиваются и не рвутся, перепаивал много раз - всё целое. П = Прочность! Китайцы, видимо, не знают такого слова 🤣

Что имеется ввиду? Чем и как промывать? Просто брал вату, смоченную в спирте, намотанную на зубочистку и несколько раз протёр участки с остатками флюса/припоя. Удивительно, что плата несколько дней проработала на 1200 МГц , а потом после перепайки периферийного модуля (рядом с платой T113) перестала работать, пока не снизил частоту ядра или не повысил его напряжение питания. Может феном паяльным что-то разогрел, в общем - Х.З. что произошло - почему плата с T113-s3 стала глючить - до тех пор, пока не подкорректировал напряжение ядра... Причем, это только одна такая плата. Остальные работают.

Через какое-то время одна из плат на базе китайского модуля 100ASK-Pro-T113 перестала запускаться. Начал копать в поисках причины, обнаружил подкуп памяти DDR, если ядро работает на 1200 МГц. Если выставить 1008 МГц, то работоспособность программ восстанавливается. Замерял напряжение питания ядра под нагрузкой - оно оказалось совсем меленьким: 0,885V Припаял впараллель резистор 1 МОм, напряжение под нагрузкой стало 0,915V. Программы стали идти на 1200 МГц из DDR. Но как оказалось этого мало, дисплей показывал короткие белые полоски - в малом количестве, возникающие в случайных местах. Припаял впараллель ещё один резистор 1 МОм, напряжение под нагрузкой стало 0,94V. Полоски на дисплее ушли. Как я понял, для нормальной работы T113-s3 напряжение питания на ядре должно быть 0,95V. А было 0,885 V. Мало того, китайцы расчитали резисторы исходя из холостого хода: Ucore = 0,6*(1 + 51K/100K) = 0,906 V, а на самом деле оказалось 0,885V. Пару часов потратил, чтобы найти причину сбоя. В начале думал, что дорожки съелись коррозией или где-то непропай и контакт окислился. Под лупой просмотрел всю плату.

Собрал второй девайсик. Провёл лабораторные испытания/замеры. Также протестировал в помещении. Работает. Следующий шаг: испытание на открытой местности на большом расстоянии, на четверть-волновые антенны.