FrSky 2.4GHz FHSS, новый игрок на рынке 2.4ГГц
Добрый день, к посту 1715: да, все верно мега 8535 собирает данные с датчиков, у меня 4-температуры-(датчики TMP36), ток-(датчик ACS754-100А), напряжение-(обычный делитель), 2-тахометра на INT0, INT1 висят-(оптрон H11L1 подключен в БК-регуляторе). Все собранное по уарту идет в приемник по известному протоколу на скорости 9600. Из шести пользовательских байтов у меня первый это указатель остальные мои данные. Мой полный кадр 15байт, в приемник пихать нужно с такой частотой чтобы битовая скорость (общаяя) была не больше 1200 (в протоколе в конце это отмечено). К посту 1717, да действительно как вы и написали такое есть что не всегда в юзерском пакете шесть байт, я тоже не знал что это за косяки при приеме, но поступаю просто: если на приеме не шесть байт, то этот кадр игнорирую. К посту 1716: с ВЧ-модуля выходит сигнал с обычного драйвера RS232, то есть он инвертированый с меняющейся полярностью, вполне достаточно поставить транзистор n-p-n перед приемным контроллером, как в схеме где описан протокол, или поставить драйвер ST232 к примеру, что я и сделал…
если на приеме не шесть байт, то этот кадр игнорирую.
Поступил так же 😛… Если данные повторяющиеся, то - ничего страшного…
Спасибо за разъяснение по поводу битовой скорости, а то переводил-переводил - так и не понял, к чему это 😦? В моей программке “запихивается” по 6 байт 10 раз в секунду… как я понял - это далеко до предела…
В протоколе еще описаны тонкости обращения с данными, если они равны 7E или 7D… Тоже до конца не сообразил, поэтому пока тупо меняю такие значения на 7F… Но такой фокус можно проделывать не со всякими датчиками… Если можете пояснить что-нибудь по этому поводу - буду благодарен!
с ВЧ-модуля выходит сигнал с обычного драйвера RS232, то есть он инвертированый с меняющейся полярностью, вполне достаточно поставить транзистор n-p-n перед приемным контроллером, как в схеме где описан протокол, или поставить драйвер ST232 к примеру, что я и сделал…
Транзистор только инвертирует, но не сдвигает? Подскажите, пожалуйста! Инвертирование я успешно делаю программно. Но в Ардуинку идет -5 +5В, а хотелось бы 0…5В. Последовательно поставить диод? (рассматриваем только прием данных в Ардуинку из ВЧ-блока)
Диод с резистором это минимум , для любителей экономить , транзистор лучше (он вам и проинвертирует), а еще лучше преобразователь уровня , но но в данном случае преобразователь уровня IMHO слегка излишество , но если бы делал не для себя а для промышленного применения то преобразователь уровня поставил бы обязательно. Транзистор IMHO самый оптимальный вариант , пример есть в описании протокола www.frsky-rc.com/…/20100921121837352.pdf только в вашем случае VCC = 5V
идет -5 +5В, а хотелось бы 0…5В.
Сделайте, как здесь rcopen.com/files/4cf5717199707300771870f3
Это из темы rcopen.com/forum/f8/topic210730
По-моему, это самое простое. Сдвиг на диоде. Инвертирую программно.
Самое простое для выполнения требований DS , но отсутствует какая либо защита.
Желателно добавить резистор между TX и диодом (ом 300 -500) и резистор между RX и GND (1-10К)
Сделайте, как здесь forum.rcdesign.ru/…/attachment....6&d=1291153777
Почти правильная схема , не хватает резистора с базы T2 на массу
Первая схема будет работать с фрискаем но если воткнуть в полноценный сом порт ±12 сгорит а при ±3 работать не будет , вторая свободна от этих недостатков
Между входом RX и GND должен быть резистор в несколько КОм… На высокоомном входе можно получить неустойчивый “0”…
не хватает резистора с базы T2 на массу
Я тоже предпочитаю ставить резисторы с базы на корпус, особенно в тех случаях, когда устройство может эксплуатироваться с не подключенным входом…
Автор схемы, наверное, не планировал использовать свой модуль без подключения к источнику данных… Поэтому посчитал резистор ненужным 😉…
Автор схемы, наверное, не планировал использовать свой модуль без подключения к источнику данных…
В жизни к сожалению не все идет по плану , проводочек отвалится например.😉
К посту 1720 для Pav_13. То что вам не понятно в протоколе это обычный байтстаффинг, это очень не сложно: Если в текущих данных (принимаемый кадр) встречается байт 0x7E, то он подменяется двумя байтами 0x7D и 0x5E, если в принимаемом кадре встречается байт 0x7D, то он подменяется на два байта 0x7D и 0x5D. Соответственно, при “разгребании” приемного буфера количество байт в нем от 0x7E до 0x7E (от стартового до стопового байта) будет разным, потому что в передаваемых данных будут проскакивать байты 0x7E и 0x7D. Учитывая вышеописанную особенность, в программке нужно делать все в обратном порядке…
обычный байтстаффинг
Вот спасибо! и главное пока не сказали я этого в описании протокола в упор не видел , и думал же как быть если в данных 7E 😃
он подменяется двумя байтами
Можно заранее заменять запрещенные значения 0x7E и 0x7D на ближайшее меньшее или большее, чтобы не было байтстаффинга. Если с датчика пришло 0x7E=126, то заменить на 0x7F=127 и отдать в приемник (аналогично, запрещенный “7D=125” заменить на 7С=124). Тогда чип внутри приемника\передатчика не будет делать подмены байтов, длина принятого слова будет постоянной. А погрешность датчика 126~127, 125~124 не критична.
А погрешность датчика 126~127, 125~124 не критична
Для напряжения или оборотов может и не критично , а я хотел туда GPS пустить, чтоб если что, искать легче было. Видимо на выходные достану это дело из долгого ящика.
Наверное можно и так делать, дело каждого, но это не правильное решение, гораздо проще делать все как говорится “по человечески” 😃, и это абсолютно не сложно и очень быстро на самом деле.
Совершенно верно! Для датчиков, контролирующих постоянно меняющуюся величину с точностью в 8 разрядов - некритично… А вот, если точность нужна выше (одного байта мало) или данные представляют собой достаточно сложную структуру (тот же GPS) - такой способ не годится…
С удовольствием посмотрел бы на правильный алгоритм разбора таких пакетов данных… Можно на С, можно ромбиками-квадратиками… Если у кого есть ссылка - дайте…
Игорю Лытневу: Правильно, доставайте, если будут вопросы или непонятки подскажу-помогу по возможности… У меня тоже мысль есть, освободить аппаратный уарт у меги для гпс приемника а в фриску “пихать” какой-нить любой ножкой, но это как время позволит.
Павлу Бакулину: Если нужно могу показать как в моей прогрммке это написано на “СИ”, но только позже, вечером скорее всего, сейчас нет моих исходников под рукой.
Да! Посмотрю с удовольствием… Может, даже пойму чего-нибудь 😃…
У меня была мысль, подключить GPS-модуль прямо к приемнику… Для летающей модели этого было бы вполне достаточно - скорость, высота, направление на базу, координаты… Летал с телеметрией от Smalltim только с GPS-модулем - вполне устраивало!
Запустил Ская через 2Ватный бустер,значения остались прежними.
Для Павла Бакулина: Нашел на флешке свои исходники, вот кусок в котором обрабатывается приемный буфер. RX_ptr - это это переменная которая после принятия стопфлага 0x7E из уарт принимает соотв. значение…
if(RX_ptr&0x80) //Если приняли буфер по UART, то разгребаем его…
{INT8U data, m=0;
for(i=0; i<8; i++) //n<=RX_ctr;
{if(RX_buf[i]==0x7D) data=RX_buf[++i]|0x20; //байтстаффинг
else data=RX_buf[i]; //байтстаффинг
switch (RX_ptr)
{case 0x81: {data_Ur[m]=data; break;} // Пользовательские данные (грузим в буфер)
case 0x82: {DATA_Fr[m]=data; break;} // Данные FrSky (грузим в буфер)
default: break;
}
m++;
}
}
Если у кого есть ссылка - дайте…
В описании протокола есть: When byte 0x7D is received, discard this byte, and the next byte is XORed with 0x20;
Упс , опоздал.
Илья, спасибо! В приведенном Вами фрагменте кода знакомые буквы вижу - попробую “вкурить” 😛…
Игорь, я пытался перевести Гуглом эту строчку из описания протокола - результат неутешительный 😦…
Вы можете растолковать эту строчку по-русски?