qczek lrs – 433mhz 1w (30dbm) lora rc link with telemetry - новая народная?
ФС и фризы - это две разные проблемы.
ФС у меня вообще никогда не было. Вообще и никогда.А вот фризы были очень часто в ближней зоне полетов, как и еще минимум у 4 человек с которыми я летаю.
Фриз - это 1-2 сек полного прекращения приема приемником. ФС в АП при этом не включается, но управление эти секунды отсутствует.
Поэтому многие ушли на Кросс, и теперь летают не нарадуются.
Это одна и та же проблема)) Просто у кого-то фс на 2сек стоит у кого-то на 1сек как у меня… и когда фриз длится 1 или 2 сек - включается фс - если нет - просто фриз… фсу предшествует длинный фриз…
Вот и я кросс заказал)))
Нет ФС - это в первую очередь функция приемника, а на неё уже реагирует АП в зависимости от установленной задержки. И я говорю о другом ФС - это когда сигнал не достигает приемника и он включает режим ФС сознательно.
В случае с фризом - я не знаю точно какова причина, но это просто некорректная работа прошивки. Связь при этом физически не нарушена.
Происходит ли ФС в этот момент, или он просто полностью отрубает выход - это как раз большой вопрос.
Судя по всему, что слышал здесь, со стороны и по собственным впечатленим, проблемы кузека в чистоте окружающего эфира и алгоритме фильтрации помех перемудрено, пожалуй…
Я летаю в сельской местности, радаров никаких, фон почти чистый, и на фризы жаловаться не приходится.
Не скажу, что их нет вообще, но 95% из них если видел и ощущал, то дома, прямо на рабочем столе.
Похоже что временами кузековскому приёмышу мешают домашний и соседские модемы, близко стоящий включенный Таранис и прочее электронное столпотворение.
это просто некорректная работа прошивки. Связь при этом физически не нарушена.
Угу. Такое впечатление, что он замер и гадает-“верить - не верить” принимаемому сигналу?
Нет ФС - это в первую очередь функция приемника, а на неё уже реагирует АП в зависимости от установленной задержки. И я говорю о другом ФС - это когда сигнал не достигает приемника и он включает режим ФС сознательно.
В случае с фризом - я не знаю точно какова причина, но это просто некорректная работа прошивки. Связь при этом физически не нарушена.
Происходит ли ФС в этот момент, или он просто полностью отрубает выход - это как раз большой вопрос.
Я Вам говорю и пишу все это т.к. я видел исходники почти всей прошивки и вместе с кузеком пытались найти причины. ФС в случае с кузеком делает только приемник либо полетник если отключить приемник. Ибо у кузека всегда выдаются данные в порт, даже если нет сигнала. При этом прошивка кузека не выдает фс столько времени, сколько указано в конфигураторе при отсутствие сигнала от передатчика. Фризы у кузека как раз и проявляются при отсутсвие пакетов от передатчика - при этом приемник выдает последние значения каналов до момента, когда наступит тот самый 1 или 2 сек или то сколько кто настроил в конфигураторе и затем просто в пакет sbus меняет один байт - делает реальный ФС для полетника…
Фризы - это в любом случае не корректная работы приемника - т.е. прошивки…
Не помню уже точно, но у него зачем-то сделана перезагрузка приемника, в случае длительного ФС, разве в этот момент может что-то выдаваться на выход?
Из того что вы сейчас написали про фризы - я вообще ничего не понял.
У меня фризы не могут появляться при отсутствии пакетов от передатчика, потому что это происходит на расстоянии 100м в прямой видимости. Хотя выглядит это именно так. Т.е. приемник указывает полную потерю всех пакетов. Но с чего вдруг, если они есть?
То как вы пишите - это не фризы, а штатная работа.
У меня фризы не могут появляться при отсутствии пакетов от передатчика, потому что это происходит на расстоянии 100м в прямой видимости
Вот как раз так и происходит - фризы не зависят от расстояния - хотя может вблизи на 2.10 их было больше - т.к. было выяснено, что auto gain работает криво - при выключении его - становится намного лучше - в 2.11 как раз его выключили.
Что такое фризы у кулрс - это когда в какой то момент получилось так что пакет прилетел но имеет crc не верный - это может быть шум или еще что - не важно - и в прошивке сделано так, что следующий пакет нужно слушать на другой частоте - переключаем частоту и ждем следующий пакет - а вдруг мы переключили частоту не в подходящий момент - и в итоге получили рассинхронизацию частот - в итоге получим потерю минимум 8 пакетов в худшем случае больше - в итоге имеем потерю связи на какое то время - к примеру на 800мс или 1с или 1.5 и т.д. это и есть фриз - в этот момент нет связи! но приемник передает полетнику последние данные о стиках - т.е. летим туда куда летели до фриза и если фриз/потеря связи длится более того времени что указано в конфигураторе - то приемник включает фс - у Вас этого может не быть если фризы были короче чем время выставленное в конфигураторе.
Основная причина лежит в правильной обработке пакетов с неверным crc и синхронизация времени переключения частот - тут elrs работает можно сказать прям очень хорошо - т.к. имеет изначально хорошую задумку про поводу этого… в кулрс с этим были проблемки - в процессе тестирования часть проблем постарались решить но мой вывод таков, что очень много надо переделать - но это не так просто т.к. уже много кода сделано… и большой косяк у самих модулей в не подключенных пинах DIO от чипа лоры - о чем китайцы думали я не в курсе…
Вот теперь понятно!
А зачем нужны пины DIO?
Вот теперь понятно!
А зачем нужны пины DIO?
Лора может выдавать по получению данных прерывания на эти пины - микроконтроллеру не нужно постоянно читать регистры по spi у лоры и заниматься не нужной работой…
Вот тут как раз все зависит от помех сторонних - ибо лора часто принимает пакеты с помехами - и чем их больше тем чаще будут проявляться проблемы с фс - ибо они напрямую связаны обработкой потярных/битых пакетов… У меня за 2 минуты бывает штук 15 или больше помех прилетает это при отключённом передатчике - просто из эфира нахавает херни и выдает процу что приняла пакет размером 9 байт.
Тогда понятно, я то в городах не летаю, поэтому проблем с фризами и fs не имею.
пакет прилетел но имеет crc не верный - это может быть шум или еще что - не важно - и в прошивке сделано так, что следующий пакет нужно слушать на другой частоте
Если переключение происходит именно по принятому пакету, независимо от его CRC, то в таком случае рассинхронизация появлялась бы каждый раз, когда прилетает битый пакет от передатчика. Другими словами, выставляем тип RSSI на “Packet Lost” и каждый раз, когда он опускается ниже 100%, то получаем фриз. Но такого не происходит.
Если переключение происходит именно по принятому пакету, независимо от его CRC, то в таком случае рассинхронизация появлялась бы каждый раз, когда прилетает битый пакет от передатчика. Другими словами, выставляем тип RSSI на “Packet Lost” и каждый раз, когда он опускается ниже 100%, то получаем фриз. Но такого не происходит.
Что Вы хотите этим сказать? Я что писал, что фризы должны быть каждый раз при утерянном пакете? Я написал в общем как происходит фриз чтобы тот кому я писал стало понятно. Понятное дело, что фриз не может быть от одного битого - т.к. один битый обработать не трудно - вот когда их несколько подряд тот там уже сложнее применительно к прошивке кулрс
В asr6505 стоит более совершенный чип лоры sx1268(2) и DIO заведены… А также стабильность частоты за счёт TCXO применения. Так что может что то и получится… Сам купил несколько таких модулей
Что получится и у кого?
Так что может что то и получится.
А портировать на этот чип кто будет то?
Тогда понятно, я то в городах не летаю, поэтому проблем с фризами и fs не имею.
знаю как минимум одно место - компрессорная станция на газопроводе - над ней всегда фс или лаги - по ходу у них телеметрия на 433 работает
Я что писал, что фризы должны быть каждый раз при утерянном пакете?
Вы написали, что переключение частоты происходит в момент приёма пакета, независимо от его CRC. Меня вот конкретно этот момент интересует. Как я себе представлял, в прошивке используется некий таймер, в течении которого приёмник ожидает пакет. Битые пакеты отбрасываются. По истечению таймера в любом случае происходит прыжок на след. частоту. Если валидный пакет пришёл раньше, чем время закончилось - используем это событие, для того, чтобы синхронизировать таймер с передатчиком. В кузеке по-другому реализовано?
Выглядит, что так. С таймером могут быть “нюансы”. Как бы там какой температурный дрифт не появился.
Рассинхрон может быть, но каждый раз, как ловим валидный пакет - производим коррекцию таймера, т.к. приёмник, фактически, понимает в какой момент времени пакет был отправлен, потому что time-on-air в Лоре фиксированный при одинаковых параметрах линка. И при потере пакетов точности таймера вполне должно хватить, чтобы какое-то время частоты переключать до восстановления связи.
Рассинхрон может быть, но каждый раз, как ловим валидный пакет - производим коррекцию таймера, т.к. приёмник, фактически, понимает в какой момент времени пакет был отправлен, потому что time-on-air в Лоре фиксированный при одинаковых параметрах линка. И при потере пакетов точности таймера вполне должно хватить, чтобы какое-то время частоты переключать до восстановления связи.
Любой пакет, будь то битый или не битый будет лететь столько времени, сколько требуется для данного режима - следовательно, принятый битый пакет уже нарушит получение валидного на этой частоте, следовательно надо переключать частоту в любом случае при получении битого пакета и ждать валидного на другой частоте
В кузеке по-другому реализовано?
Именно по другому - это Вам не elrs…
Рассказывать все не имею права… но и переписывать все автор не будет… так что пользуйтесь тем, что есть… 😃
Рассказывать все не имею права… но и переписывать все автор не будет… так что пользуйтесь тем, что есть…
Теперь начал понимать ваш пассаж из соседней темы… 😃 Ну да, почти тупик.
Хотя 1.92 по прежнему рабочая версия и на ней вполне можно летать.
Но не на квадре и не в заброшках…
Привет всем!
Кто-то пробовал qczek скрещивать с Ardupilot/Arduplane на базе F405?
Inav видит, всё отлично, а арду ни в какую. В мануале написано, что должно само определиться ,а оно не определяется. СТранно, Sbus же.