Baychi OpenLRS - дружелюбная ЛРС с широкими возможностями )
кроме как выставить “какое надо”. Мне (и Александру) надо еще FS на приемнике запрограммировать на меньшее значение, чем “какое надо”.
Ну и в чем проблема? Арду рекомендует выставлять расходу 1000-2000, а лучше 1100-1900. Я fs min делал 1020 на экспертовской, сейчас на байчи поменьше. За пределы 988 не выходит. Понимаю что не 950, но с этим значением у меня только frsky летал (по моему)
Я fs min делал 1020 на экспертовской, сейчас на байчи поменьше.
А сколько у вас реально выдается при минимальном газе, лимитах 100%, триммере в нуле ?
А сколько у вас реально выдается при минимальном газе, лимитах 100%, триммере в нуле ?
Сейчас точно не скажу. Сначало у меня была JR-ка и FrSky (модуль и приемник), там fs=950 работал, потом JR-ка и 2G(по сбас), там уже пришлось играться этим параметром. Но расходы были 100% и триммера в нейтрали. Для программирования FS загонял триммер вниз до упора, увеличение расхода до 150% не приводило к выходу за пределы (не помню какие, но 950 не доставало). Сейчас пересел на таранис+2G (пока байчи) тут лимиты вообще большие, поэтому приходится ограничивать расходы на аппе, чтобы в МП газ (ну и другие каналы) был 1020-1980
Для программирования FS загонял триммер вниз до упора, увеличение расхода до 150%
Вот. У меня же на er9x и байчи, триммер вниз не приводит к сдвигу нижней границы (верхняя только уменьшается).
Вот. У меня же на er9x и байчи, триммер вниз не приводит к сдвигу нижней границы
а-а-а, тогда ясно, и увеличение расходов тоже не снижает
и увеличение расходов тоже не снижает
именно так.
Вот и остается, летать с триммером верх всегда. Что в общем то не сильно напрягает конечно (меня), а вот Александр как то захотел до истины докопаться 😃
Подождите. А что мешает откалибровать арду на диапазон 1000-1900 (или какой нравится, лишь бы нижний был 1000). А потом сделать фейлсейф на 988?
Официальная инструкция Ардупилота 😃 которая предлагает именно сдвигать ниже фактического минимума. Зачем, я пока тоже не понял. Вечером буду тестить.
именно так.
Вот и остается, летать с триммером верх всегда.
Андрей, а в er9x есть еще elimits - они очень удобно регулируют низ и верх вообще без триммера.
Пока всё, я убежал, удачи
Прибежал:)
… компилирую.
Проверяю и радуюсь , либо, если "что-то пошло не так " слегка огорчаюсь и меняю код на исходный,
Ведь ни кто не стал проверять практически такой вариант?
Ну что ж - значит при экспериментах ни одного … экспериментатора не пострадало 😃
Нашел я еще одно место в исходниках, где обрабатывается значение длительности импульсов РРМ и как порог для обработки - вы будете смеяться, но опять “магическое” число 1976 (которое удвоенное 988 😃).
Это место в модуле rfm22b.ino:
word ppmCode(byte ch) // преобразование мкс PPM в 11 битный код
{
word pwm=PPM[ch]; // берем длительность импульса в мкс*2
if(pwm < 1976) pwm=0;
else if(pwm > 4023) pwm=2047;
else pwm=pwm-1976;
return pwm;
}
Здесь идет преобразование удвоенных микросекунд к нужным величинам, которые позже будут обработаны и отправлены в передатчик.
Что видно?
Всё, что было короче 1976 (988мкс) превращается в ноль (не напоминает ли вариант, уже попадавшийся выше, но при обнаружении файлсейва?)
// нет PPM - нет и передачи
Всё, что было больше 4023, обрезается до 2047 (4023-1976=2047)
Всё в диапазоне от 1976 до 4023, после вычитания 1976, займет место в диапазоне от нуля до 2047.
И в таком виде будет обрабатываться дальше.
Но если мы обрезали до нуля всё, что было меньше 1976 (988мкс), то характер изменения длительности меньше 988мкс уже потерян (присвоено значение, соответствующее нулю).
Получается, что не стоит ждать после этого импульсов, соответствующих меньшим значениям. Вернее, какой-то импульс может быть на выходе (нужно копать дальше, может исходников будет мало и придется лезть в даташит, но дальше уже не полезу, потому что прошивка работает убедительно, не нужно мешать ей работать), но он будет соответствовать любым импульсам до 988мкс. Может кривовато объяснил, извиняюсь.
Кто-то скажет: - А у меня не включен режим 11бит, а тут речь про 11 бит.
Это неважно, 11 бит будут вычислены, но если выбрано только 10 бит, то и переданы дальше будут только 10 бит из 11 (конечно будет касаться только точности).
вы будете смеяться, но опять “магическое” число 1976 (которое удвоенное 988 ).
Это место в модуле rfm22b.ino:
word ppmCode(byte ch) // преобразование мкс PPM в 11 битный код
Этой функции нет с 30 ноября 2013 😃
Сейчас эта логика находится в функции mks2code(). И, повторюсь, она зависит от регистра 5. В представлении футабы, длина импульса может опускаться до 880.
Плюс, за счет расширения серводиапазона на приемнике, даже в представлении эксперта можно уйти до 900, если я правильно посчитал (см. BufToServo() в functions.ino).
Кто-то скажет:
Вам бы свежие исходники скачать 😃
Вчера мы многое поняли:
Во-первых, мишин планер можно использовать в качестве терминала для просмотра ППМ 😃
Во-вторых, действительно, значение меньше 988 в терминале является минимальным, даже в случае, если в аппаратуре установлено число меньшего значения, отсюда можно сделать вывод что мои опасения по поводу триммирования нижней границы сигнала прошивкой полностью оправдались. (Еще раз спасибо за совет, обсуждать это в теме Ардукоптера - это было проницательно!😃 )
Логика работы прошивки явно такая - все что меньше 988 = 988.
Интересно, конечно, где находится этот код.
Вывод: прошивка передатчика сразу выводит в сигнале ППМ максимальные значения каналов, и они не могут быть увеличены с помощью прошивки аппы er9x такими функциями как WEIGHT канала, или Elimits. Что вообщем-то ни хорошо, ни плохо.
Спасибо всем за помощь.
Логика работы прошивки явно такая - все что меньше 988 = 988.
Интересно, конечно, где находится этот код.
Доктор, меня все игнорируют 😉
Доктор, меня все игнорируют
Кто там следующий, чего не проходите? 😃
Вам бы свежие исходники скачать
Спасибо за замечание:) Я ведь говорил, чего тут копаться, если прошивка замечательно работает, нечего ей мешать… Скорее всего так и получилось - в самой современной прошивке не оказалось принципиально ценных добавлений для меня к устойчиво работающей версии.
Этой функции нет с 30 ноября 2013.
Сейчас эта логика находится в функции mks2code().
Ты знал! Ты знал! 😃 А сказал бы раньше, я и не полез бы в механизьм 😃
Ну хоть предположительно нашли ответы, уже хорошо.
Сделали с дайверсити и акком для маяка.
действительно, значение меньше 988 в терминале является минимальным, даже в случае, если в аппаратуре установлено число меньшего значения, отсюда можно сделать вывод что мои опасения по поводу триммирования нижней границы сигнала прошивкой полностью оправдались. Логика работы прошивки явно такая - все что меньше 988 = 988. Интересно, конечно, где находится этот код.
Руководство пользователя от baychi:
диапазон изменения канальных импульсов в режиме Эксперт: 988-1500-2011 мкс;
диапазон изменения канальных импульсов в режимах 2 и 3 - Futaba: 880-1520-2159 мкс;
можно попробовать
Сделали с дайверсити и акком для маяка.
туда еще проц с большим объемом памяти, что бы и прошива байчи влезла и маяк тигромуха 😃
Они там уже на стме версию мутят! Вместе с мпу. Там и маяк и сразу полетный контроллер получается!
Интересно по дайверсити - на сколько схемотехника правильная. И чего дорого так, там один мелкий чип этим занимается, ну и фтди еще за 3$.
Там и маяк и сразу полетный контроллер получается!
ну наффиг. Объединять приемник с маяком есть смысл, а с полетным уже нет. Да и потребление должно быть мелкое, что бы акка резервного на сутки хватало.
Для мелких коптеров это хороший вариант. И только. Чтобы всякие сс3д не ставить. Только кто код интегрирует - неясно. Поэтому уже год они мутят…
А маяк - многие сказали, что нужен отдельный, когда я с подобным же предложением выступил!
А как вы думаете, возможно настроить фейлсейф так, что бы ничего не было на выходах в этот момент?
Если ещё актуально, то 149 строку OpenTiny_Rx.ino изменить на:
if(receiver_mode==1 && Servo_Number <= MAX_PPM_OUT && failsafe_mode == 0) {
было:
if(receiver_mode==1 && Servo_Number <= MAX_PPM_OUT) {
в режиме ФС на выходе не будет PPM.
Если ещё актуально, то 149 строку OpenTiny_Rx.ino изменить на:
А почему не 120ю? 😃
А почему не 120ю?
Потому что тогда теряется возможность использования PWM выходов в режиме FS.